Search Consoleでドメインプロパティを使う

　先日、常時SSL化を行ったサイトをSearch Consoleに登録する際に、新しくSearch Consoleに追加「ドメインプロパティ」を使うべきか、従来からある「URL プレフィックス プロパティ」を使うべきか少し悩みました。結局、httpからのアクセスとhttpsからのアクセスをごちゃまぜにしないで分けて分析した方が良いと考えて「URL プレフィックス プロパティ」で登録しました。

　ところが、同じサイトのhttp:、httpsなどの違いによる異なるバージョンを「URL プレフィックス プロパティ」で個々に登録すると、それぞれが別のサイトとしてインデックスされ、SEO上での評価が分散する可能性があるとの情報もあります。

　そこで、やはり「ドメインプロパティ」を使ってみることにしました。

　Search Console画面左側にあるメニューの「サマリー」の上にあるプルダウンメニュー（プロパティのURLが表示される所）から「プロパティを追加」を選択すると、「プロパティ選択」のポップアップが表示され、「ドメイン」（ドメインプロパティ」）、または「URL プレフィックス」（URL プレフィックス プロパティ）のいずれかの方法でプロパティを追加できるようになります。

　今回は、「ドメインプロパティ」を使いますので「ドメイン」URLの欄に登録するサイトのドメイン名と入力し「続行」ボタンを押します。

　すると、「DNS レコードでのドメイン所有権の確認」ポップアップが表示されます。

　「google-site-verification=」で始まるコード（TXTレコード）をサイトのDNS設定にコピーするように指示されますが、知識不足のため良く理解できません。

　サイトはWebARENA SuiteX上にありますので、SuiteXでのTXTレコードの設定方法について調べてみました。

　すると、WebARENA SuiteXの説明から、「TXTレコード」について以下のことがわかりました。

• 「TXTレコード」＝「送信ドメイン認証」で用いられるコード
• 「送信ドメイン認証」＝メールを送信するメールサーバーの情報をDNSサーバーに記載することで、なりすましを防ぐ機能

　要するに、メールのなりすましを防ぐための仕組みらしいですが、これがSerch Consoleでの認証とどう関わって来るのかよくわかりません。とりあえず、サイトに「TXTレコード」を追加してみます。

　WebARENA SuiteXでは、「サイトマネージャ」-「サイト管理」-「送信ドメイン認証の設定」から設定するドメインを選択した「編集」ボタンを押します。すると、「TXTレコードに追加するIPアドレス」の項目がありますが、この画面では「TXTレコード」は追加できません。「変更」ボタンを押すと、設定内容の確認画面が表示されます。ここで実際の「TXTレコード」値が表示されますが、それを編集することは出来ません。どうやら、前の画面で追加したIPアドレスに基づいて「TXTレコード」が生成されるようですが、「TXTレコード」そのものを直接編集することは出来ないようです。これでは、Search Consoleの要求する「TXTレコードのDNS設定へのコピー」を実現することは出来ません。

　WebARENA SuiteXではSearch Consoleの「ドメインプロパティ」が設定できないのだろうか？　とりあえずこの問題はペンディングとします。

SSL対応：ページビュー数が減少？

　昨日、常時SSLへの移行が完了しました。その影響はどうか？　ページビュー数を確認すると、前日の1/3以下に減少しています。アウトドアレジャー関連のサイトなので、天候悪化の影響で、常時SSL化以前にも、この程度までことはありました。昨日は大風接近による天候の悪化が少なからず影響しているのかも知れません。しかし、常時SSL化の影響もありそうです。数日は状況を小まめに監視したいと思います。

SSL対応：アナリティクス、Google Search Console、Google AdSenseの設定

　前回の投稿でサイトのSSL化が完了しました。今回は最後の仕上げとして、SSL化したサイトに対してアナリティクス、Google Search Console、Google AdSenseの設定を行います。

　SSL化したページは、各ページに記載したアナリティクスのトラッキングコードを変更する必要はありません。httpでアクセスしていた時のトラッキングコードをそのまま流用できます。

　SSL化に伴い必要となるアナリティクスの設定変更は二か所。「デフォルトのURL」と「ビューの設定」の「ウェブサイトのURL」です。

　「デフォルトのURL」は、アナリティクス画面左側にあるメニューの下側にある「管理（歯車アイコン）」-「プロパティ設定」から設定することができます。「デフォルトのURL」のプルダウンをhttpをhttpsに変更します。

　「ウェブサイトのURL」は、「管理（歯車アイコン）」-「ビューの設定」から設定することができます。「ウェブサイトのURL」のプルダウンをhttpをhttpsに変更します。

　以上でアナリティクスの設定は完了です。

　最近サーチコンソール（Google Search Console）では、「ドメインプロパティ」が設定できるようになりました。これを使えば（ドメインが同じなら）常時SSL化前のサイト（http）と常時SSL化したサイト（https）をまとめて管理できそうですが、今回は新しいプロパティとして常時SSL化したページを追加しました。新しいプロパティは、現バージョンのサーチコンソールでは、画面左側のメニューの「サマリー」の上にあるプルダウンメニュー（プロパティのURLが表示される所）から追加することができます。

　さらに、新しく追加した常時SSL用のプロパティにサイトマップを送信します。

　Google AdSenseに関しては、常時SSL化に伴う設定変更は必要なさそうです。

SSL対応：httpへのアクセスをhttpsにリダイレクトする

　これまでに、非SSL領域（http）にあったファイルを、すべて完全SSL化してSSL領域（https）にアップロードすることが出来ました。

　いよいよ、httpへのアクセスをhttpsにリダイレクトしてユーザーが常にSSL領域のページを見るようにしたいと思います。

　今回は、全ページをリダイレクトするので作業は至って簡単です。非SSL領域（http）のルートにある.htaccessを以下の様に設定します。

RewriteEngine on
 RewriteCond %{HTTPS} off
 RewriteRule ^(.*)$ https:///books-nekoya.jp/$1 [R=301,L]

　修正した.htaccessを非SSL領域にアップロードしたら、念のため正しくリダイレクトされているかいくつかのファイルで検証します。ブラウザで非SSL領域のファイル(http)を開いてSSL領域（https）が表示されればリダイレクト自体は動作していることが確認できます。それが301リダイレクトであるかどうかを知るには、「301リダイレクト　確認」などのキーワードで検索すれば、そのためのツール（サイト）を容易に見つけることができます。

　ここまでで、SSL化に伴うサイトの設定は一応完了しました。

SSL対応のためのファイルの再アップロードとファイルの修正（4）

　前回は、.htaccessでサイトの非SSL領域へのリンクをSSL領域にリダイレクトする方法について考えてみました。

　その後、早速.htaccessを修正してSSL領域のページが（安全でないとの）警告なしで表示されるか調べてみました。ところが、警告はなかなか消えません。

　Javascriptなどは正しくリダイレクトされていますが、どうもCSSが読み込めていないようです。

　.htaccessによるCSSファイルのリダイレクトに関して、不具合が発生することは良くあることなのか？　参考になりそうな情報を検索してみましたが見つかりません。通常の場合であれば、つまづくような問題ではなさそうです。

　.htaccessの設定に問題があるのか？　そこでブラウザでそれぞれのCSSのアドレスを入力してみると、正しくリダイレクトは行われています。どうやら.haccessの問題ではなさそうです。

　さらに調べを進めていくと、bootstrap（レスポンシブデザインのためのCSSライブラリ）で問題が発生していました。次のbootstrapを組み込んでいる行のアドレスをhttpからhttpsに変えたり、行そのものをコメントアウトすれば、他のCSSは読み込めるようになります。

<link href="http://books-nekoya.jp/css/bootstrap.min.css" rel="stylesheet">

　この時点で、bootstrapだけの問題かと思われましたが、他のHTMLではbootstrap読み込みの部分を修正しても、他のCSSが読み込まれません。ファイルによってはJavascriptも読めなくなっています。

　そもそも、スクリプトの読み込みを修正せずに.htaccessのリダイレクトだけで対応しようとすること自体が非常識なのだろうか？　

　この問題については、これ以上の追及を断念し、地道にURLをhttpからhttpsに書き換えていくことにします。。

　まだ非SSL領域からSSL領域への移行作業は進行中なので、HTMLにリンクされている多くのファイルがブロックされブラウザは「安全でないサイト」の警告を表示したりします。どのファイルがブロックされているのか調べるには、chromeでは、ブラウザウィンドウ右上のchromeの設定から「その他のツール」-「デベロッパーツール」を選び「Networkタブ」を開きます。「デベロッパーツール」は[Ctrl]+[Shift]+[i]でも開きます。

　「デベロッパーツール」の「Console」タブを開くと、「Mixed Content」（httpsからhttp上のリンクを参照）として警告が出ていますのでこれをhttps（SSL領域）を参照するように修正します。

　こうしてルート直下のhtmlは全て完全にSSL対応することが出来ました。

　今思えば、HTMLやJavascript内のhttp（非SSL領域）へのリンクを残したまま、.htaccessでのリダイレクトで対応できるという考えそのものが間違いだったようです。つまり、HTML内やJavascript内のURLは全てhttpからhttpsに書き換える必要がある様です。

　これに気づいたとき、その作業の大変さに少しぞっとしましたが、エディターの「Grepして置換」機能を使えば思ったほど大変な作業ではありませんでした。

SSL対応のためのファイルの再アップロードとファイルの修正（3）

　前回はSSL用に.htaccessを修正しました。と言っても、今は不要になったリダイレクトを削除しただけで、実質的には非SSL版と変わりません。

　今回はSSL対応のためのリダイレクトを.htaccessに加えていきます。

　ファイルをまるごとSSL用ディレクトリ（/ssl）に最アップロードして、非SSL領域の.htaccessで丸ごとSSL領域にリダイレクトすれば簡単なのかもしれませんが、今回はディレクトリ単位でSSL領域にアップデートして、様子を見ながら作業を進めていきたいと考えています。SSL領域のファイルの内部リンクは、非SSL領域のファイルを参照していますので、それを非SSL領域の.htaccessでSSL領域にリダイレクトさせてみます。

　ところで、リダイレクトには「301リダイレクト」と「302リダイレクト」あります。

　「301リダイレクト」は、恒久的なページの移動を意味するリダイレクトです。.htaccessでは次のようにRedirectの後にpermanentキーワードを付けてリダイレクトを指示します。

Redirect permanent /file1.html file_new.html

　これに対して、「302リダイレクト」は、トラブル発生時などの一時的なページの移動を意味するリダイレクトです。.htaccessでは次のようにRedirectの後に tempキーワードを付けてリダイレクトを指示します。

Redirect temp /file1.html file_new.html

　SEO上は「301リダイレクト」はリダイレクト前のページの評価がリダイレクト後のページに継承され、「302リダイレクト」では継承されないと言われたりもしますが、Googleは両者を区別しないという情報もあります。どちらが正しいのかよくわからないでので、今回は念のため「301リダイレクト」を使うことにします。

　以前のページの評価をリダイレクト先に継承し続けるために、一度設置した「301リダイレクト」は解除してはならないらしい。つい、うっかりして非SSL領域の.htaccessを消してしまったりリダイレクトを解除してしまわないか少し心配です。

SSL対応のためのファイルの再アップロードとファイルの修正（2）

　今回は、/ssl/homeにアップロードする.htaccessの内容を見直し、必要であれば修正します。

　.htaccessをファイルの先頭から精査します。

　まず最初にあるのは、

RewriteEngine on

　これって、なんだっけ？　これを書いたのは数年前なのですっかり忘れていたが、リダイレクト処理を記述するために必要らしい。これはそのまま残す必要がある。

　次にあるのは、ページ表示速度改善のための圧縮ファイルの設定。ファイルをgzファイルに圧縮することで表示速度を改善することができますが、そのための設定です。

##圧縮
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule .+ %{REQUEST_URI}.gz

#スタイルシート (.css)
<FilesMatch "\.css\.gz$">
 ForceType text/css
 AddEncoding x-gzip .gz
</FilesMatch>

#Javascript (.js)
<FilesMatch "\.js\.gz$">
 ForceType application/x-javascript
 AddEncoding x-gzip .gz
</FilesMatch>

#HTML (.html)
<FilesMatch "\.html\.gz$">
 ForceType   text/html
 AddEncoding x-gzip .gz
</FilesMatch>

　これも、そのままで良いでしょう。

　ブラウザにキャッシュさせる時間をファイルの種類別に設定します。キャッシュさせる時間を長く設定すれば、繰り返し表示される場合に表示時間を短縮できますが、ファイル更新の反映が遅れます。

RewriteRule \.php$ - [L,E=X_CACHE_PATTERN1:]
RewriteRule \.html$ - [L,E=X_CACHE_PATTERN2:]
RewriteRule \.(css|js)$ - [L,E=X_CACHE_PATTERN3:]
RewriteRule \.(gif|jpe?g|png)$ - [L,E=X_CACHE_PATTERN4:]


# For CSS,JavaScript files
#Header set Cache-Control "max-age=600" env=X_CACHE_PATTERN3

# For Image files
#Header set Cache-Control "max-age=86400" env=X_CACHE_PATTERN4

　設定内容には改良の余地もありそうですが、SSL化に関して必要な修正はありません。

　あとは、Redirect temp によるURLリダイレクトの設定が続きますが。すべてウェブマスターツール（現在のサーチコンソール）で発生した「ファイルが見つからない」エラーの対策なので、SSL版では削除します。

　ちなみに、Windowsで.htaccessのような.がファイル名の先頭に来るファイルを作るには、メモ帳などのテキストエディタでファイルを保存する際にファイル名を"と"で囲みます。.htaccessの場合は".htaccess"というファイル名で保存します。

SSL対応のためのファイルの再アップロードとファイルの修正（1）

　WebARENAのWebサイトのSSL設定が完了しました。最初の目論見では、WebARENAに依頼したSSL証明書の設定が完了すれば、すでにアップロード済みのファイルが自動的にhttpsでアクセスできるはずでした。しかし、httpでアクセスするには、/sslにファイルをアップロードする必要があることがわかりました。なんだか、ちょちょいとサーバーの設定を変更するだけで出来そうな気もしますが、そう思えば思うほど、これからの作業が面倒に感じられて、ついついため息が出てしまいます。

　これからSSL化に伴って作業を進めるうちに、アップロード先ディレクトリだけでなく、他にも面倒な作業が待ち受けていそうで不安な気持ちにもなります。しかし、できるだけ早く作業を進めなければ、SSL証明書の有効期限はどんどん少なくなってしまいます。

　つい愚痴が出てしまいましたが、作業を開始することにします。

　まず、httpのルートディレクトリ /home のファイルを /ssl/home にアップロードしました。そして、index.htmlにアクセス。すると、スクリプト類がまだhhtpを参照しているので、ページのあちこちがブロックされて正しく表示されません。最初は、こんなものです。

　ところで、ルートには.htaccessなどの設定ファイルがあります。これらの設定ファイルがこのままでいいのか検証する必要もあります。ついでに、今は使わなくなったゴミファイルを削除していきます。

　内部リンクをどうするか？　という問題については、すでに存在するファイルのリンク（http）をすべてhttpsに書き換える時間も気力もないので.htaccessでリダイレクトすることにします。今後追加するリンクについても、httpsではなく、httpを使うことにします。その理由は、なんらかの理由でSSL証明が切れた場合、ファイルを/ssl/homeから/homeに移動すればサイトの運営を続けられるからです。ただ、ブラウザがhttpサイトへのアクセスに対する警告表示の際に、httpからhttpsへのリダイレクトを適切に判断してくれるか少し不安もあります。もしそうでなければ、途方もない作業が待ち受けていることになります。

　今わかっている範囲でまとめると、今後、次のような作業が必要となります。

• .htaccessなどの設定ファイルの修正
• 不要ファイルの削除
• /sslへのファイルのアップデート
• httpからhttpsへのリダイレクト

WebARENA SuiteXで独自SSLを設定（2）

　先日WebARENAに設定依頼したSSL設定が完了しました。

　証明書の有効期限は、2020/8/4まで。グローバルサインでの証明書取得は即時だったものの、WebARENAでのSSL設定が最短5営業日だったため、有効期限は1年未満になってしまいました。来年、証明書を更新するときにシームレスにSSL対応を続けるにはどうすればいいのだろう？　次回更新時までに解決策を見出さなければなりません。

　さて、早速そのサイトにアクセスしてみました。まず、URLはhttp:のまま、サイト内の特定のファイル https://domain/foo.htmlにアクセスしてみます。https://domain/foo.htmlにリダイレクトされるかと思いきや、そうはなりません。ブラウザはファイルを見つけることができません。

　自動でリダイレクトされないとすれば、直接httpsを指定してみればどうなるだろうか？　https://domain/foo.htmlでアクセスしてみました。これも、ブラウザはファイルを見つけることができません。

　トップページへのアクセスはどうだろうか？　https://domain/でアクセスしてみます。今度は、以前に使っていた共用SSLのページが表示されました。

　共用SSLの設定を解除する必要があるのだろうか？　WebARENAの管理ツール「サイトマネージャ」で共用SSLの設定を確認するとすでに共用SSLは解除されています。

　共用SSLの設定は解除されているのに、なぜ共用SSLで使っていたファイルが表示されるのだろうか？　共用SSL用のhtmlのホーム /ssl/home をFGTPで覗いてみると、以前に使った index.html が残っていました。これが表示されていたのです。とすれば、SSL用に改めてファイルをアップロードする必要があるのだろうか？

　改めてWebARENAのドキュメントを調べてみると、独自SSLの場合も/ssl以下にファイルを置かなければならない様です。

　今後の作業をまとめると、(1) /sslにファイルをアップロードする (2) hostsでhhtpへのアクセスをhttpsにリダイレクトする

　結構な作業になりそうです。

WebARENA SuiteXで独自SSLを設定（1）

　WebARENA SuiteXでサーバーを立ち上げているのですが、アクセス数向上のためにSSL化することにしました。

　最初は、WebARENAが提供する「共用SSL」を使って追加のコストの発生を回避したいと考えていたのですが、ドメインが変わることで内部リンクのすべてを書き換えなくてはなりません。サイトを立ち上げる段階なら「共用SSL」という選択肢もありそうですが、すでに大量のファイルが存在するサイトでは、リンク修正のために先が全く見えないほどの時間がかかると思えば現実的な選択肢ではありません。そこで今回は、「共用SSL」の使用を断念し、「独自SSL」としてSSL化することにしました。

　「独自SSL」でSSL化するには、サイト独自のSSL証明が必要となります。WebARENA（NTTPC）ではSSL証明を発行していませんので（*!）、外部の業者からSSL証明を発行してもらう必要があります。そのためにコストが発生します。さらに取得したSSL証明をサーバーに設定する作業をWebARENAに依頼する必要があります。ここでもコストが発生します。

　SSL証明を取得するために、まずWebARENA SuiteXのサイトマネージャの「Web & FTP管理」-「独自SSL」-「CSR・秘密鍵の作成」から、SSL認証局（業者）に提出するためのCSR(証明書署名要求)を作成します。「CSR・秘密鍵の作成」のページでは、次の項目を設定する必要がありますが、入力フォームにしっかりと説明や事例が書かれていますので迷うことはないと思います。

• 「鍵長」...2048ビット（デフォルト。この項目は変更できません）
• 「コモンネーム」...SSLホームページのURLとして使用される名前
• 「組織名」...今回設定したサイトは会社組織所有のサイトではなく個人サイトなので空白にしました
• 「部門名」...SSLの証明書を使用する部署またはグループの名前。今回設定したサイトは会社組織所有のサイトではなく個人サイトなので空白にしました
• 「国名」...国名。JP（日本）に設定しました（デフォルト）
• 「都道府県名」...都道府県名を半角英字で入力
• 「地域名」...市区町村名を半角英字で入力

「サイトマネージャー」でCSRを作成する

　必要項目を入力したら、「作成」ボタンを押します。

　しばらくすると、生成されたCSRが記載された次のようなテキストファイルがダウンロードできるようになります。

「サイトマネージャー」からダウンロードしたテキストファイル（取得したCSR）

　このファイル中の-----BEGIN CERTIFICATE REQUEST-----から-----END CERTIFICATE REQUEST-----までがCSRです。これをSSL認証局に送ってSSL証明を発行してもらうことになります。それから、WebAREに対して、SSL認証局から取得したSSL証明のサーバー設定依頼を行う際に、このファイル中に記載されている受付番号が必要となりますので、少なくともそれまではこのファイルは大事に保管しておく必要があります。

　さて、ここまででSSL認証局にSSL証明を発行してもらうための「CSR」が準備できました。次にどこのSSL認証局を利用するか考える必要があります。今回は「GlobalSign」からSSL証明を取得することにしました。なぜ「GlobalSign」を選んだかと言えば、WebARENAの「独自SSL」の説明のなかに「GlobalSign」の名前があったからという単純な理由からです。少なくとも、取得したSSL証明がWebARENAで設定できないということはないはずです。

　「GlobalSign」では、現時点でSSL認証に関して3種類の商品があります。

• 企業認証SSL...59,800円/年　最短即日で発行　運営組織の実在性を認証
• EV SSL...128,000円/年　最短10営業日で発行　世界最高基準の認証　最短10営業日
• クイック認証SSL...34,800円/年　最短2分で発行　書類不要

　今回SSL設定するサイトは個人サイトなので「クイック認証SSL」を選択しました。

　「GlobalSign」での「クイック認証SSL」申込フォームについては、スクリーンショットなどを撮っていなかったため詳しい説明は省略させていただきますが、入力項目に何を入力すればよいのか迷うような項目はありませんでした。この入力フォームで「CSR」を入力する項目がありますので、WebARENAのサイトマネージャで作成したCSR（-----BEGIN CERTIFICATE REQUEST----- と -----END CERTIFICATE REQUEST----- で囲まれたブロック）をコピー＆ペーストします。

　申込フォームの最後で、結果（SSL証明書）の受け取り方法の選択があります。今回は、メールでの受け取りを選択しました。

　申込フォームでの申し込みが完了してから、わずか数分でSSL証明書を含むメールが届きました。速い!!

「GlobalSign」から届いたメール（取得したSSL証明）

　取得したSSL証明をサーバーに設定する作業をWebARENAに依頼します。それには「サイトマネージャ」の「WEB & FTP管理」-「独自SSL」-「SSL設定依頼（証明書提出）」のフォームを使います。

　このフォームでは、次のような項目を入力します。

• アドミンアカウント...admin@IPアドレス
• お客さま名...法人の場合は法人名
• 使用ドメイン名...SSL証明書を設定するサイトのドメイン名
• SSL用 KeyPair 受付番号...CSR生成の際にダウンロードしたテキストファイルに記載されている受付番号
• 認証サービス会社...SSL証明書取得の際に利用した認証サービス会社
• SSLサーバID (証明書)
• 認証局（CA）の証明書
• メールアドレス...WebARENAからの受領メールなどを受け付けるメールアドレス
• 備考

　ここで問題に遭遇。「GlobalSign」から届いた証明書は以下の三種類です。

• 証明書 RSA/SHA-256
• 中間証明書
• 証明書＋中間証明書（PKCS7形式） RSA/SHA-256

　これに対し、「SSL設定依頼（証明書提出）」のフォームでは「SSLサーバID (証明書)」と「認証局（CA）の証明書」を要求されます。WebARENAに質問したところ、「SSLサーバID (証明書)」　には「証明書 RSA/SHA-256」を、「認証局（CA）の証明書」には「中間証明書」を設定すれば良いことがわかりました。つまり、「GlobalSign」のいう「中間証明書」とは「認証局（CA）の証明書」の事らしいです。

　WebARENAにSSL証明書の設定を依頼すると「SSL設定手数料」（8,000円 税別）がサーバー設定が完了した翌月の請求に合算されます。

　SSL化の知識の乏しい状態から、WebARENAのサイトの説明を頼りに「CSR作成」（WebARENAのサイトマネージャ）→「SSL証明書の取得」（GlobalSign）→「サーバーへのSSL証明書の設定」（WebARENAのサイトマネージャ）と作業を進めて来ましたが、（証明書設定に関する質問の時間を除けば）おおよそ1時間ほどで作業が完了しました。

*1　2019年8月5日の時点で、WebARENAでは「シマンテックウェブサイトセキュリティ」や「GlobalSign」からSSL証明を取得する作業を代行するサービスがあります。このサービスを使えば、SSL証明取得料金、またはSSL証明設定料金が割引されます。今回は急いでWebAREAの説明を斜め読みしたため、見逃していました。これに気づいていればもっとコストを抑えられたのにと後悔しています。次回はこのサービスを利用するつもりです。

Googleアナリティクスを使ってBloggerで作ったブログへのアクセスを調べる

Googleアナリティクスを使ってサイトへのアクセス状況を調べるには、サイト内の各ページにトラッキングIDを埋め込む必要があります。

トラッキングIDは、UA-132780834-1のような形式のIDです。

通常は、アナリティクスが提供するJavaScriptを各ページに貼り付けてトラッキングコードを埋め込みますが、Bloggerでは設定-その他の「アナリティクスのウェブ プロパティ ID」にトラッキングIDを設定することで、自動的に各ページにトラッキングIDが埋め込まれるようになります。

VexTab

　VexTabはHTMLなどのWebドキュメントで楽譜を表示できるようにするためのAPI「VexFlow」の簡易版的な存在で、簡単な専用言語でWebで表示可能な楽譜を作ることができます。最近その使い方を調べて、サイトにまとめました。機能的には、長さの異なる音符からなる和音や、長さの異なる音符間のタイやスラーができないなど、まだ改良の余地はありますが、それ以外は十分に実用に耐えうる出来栄えだと思います。

options width=800 font-size=10 tabstave notation=true tablature=false key=E time=C notes :16 D-G/5D-F-D/6G/5 :32C-G-A/5C/6 :16D/6 B-G /5:32C-G/5C-E/6 text :256,.9,#p,#p tabstave notation=true tablature=false key=E time=C notes :8 (E/4.B/4)(G/4.E/5)(E/5.B/5)(A/4.E/5)(E/4.B/4)(G/4.E/5)(E/5.B/5)(A/4.E/5) text :8,.11,#pedal_open options space=20

schema.orgで定義されている構造化データ型

　schema.orgのスキーマは型のセットであり、それぞれがHTML microdataなどで使用されるプロパティーに関連付けられています。それぞれの型は階層構造になっています。 　schema.orgのプロパティは、次のように分類されています。

プロパティ	説明	例
Action	行為	移動, 食事, 投票など
CreativeWork	創作活動	記事, ブログ, 本, ゲーム, TV
Event	イベント	ビジネスイベント, フェスティバル, 音楽イベント
Intangible	ユーティリティクラス	ブランド, バス旅行, 試合, 注文, デリバリーサービス
Organization	組織	航空会社, 株式会社, 教育組織, NGO
Person	人
Place	場所	宿泊施設, 管理地域, 公共施設, 山/川/湖など
Product	製品やサービス	シリアルなどで特定される個々の製品, 製品モデル, 類似製品

HTML Microdata

　HTML Microdata使用すると、HTML中に既存のドキュメントと並行して、ネストされた「名前-値」のペアのグループを定義できるようになります。HTML仕様ではHTML5から使用可能となっています。 　Microdataの基本構造となるのは、「名前（name）」と「値（value ）」のペアで、これは「プロパティ（property）」と呼ばれます。プロパティをグループ化したものを「アイテム（items）」と呼びます。 　定義の順番としては、アイテムを先に作り、そこにプロパティを追加していきます。アイテムを作るには、itemscope属性を使用します。アイテムへのプロパティ追加には、アイテムの子孫のいずれかでitemprop属性が使用されます。

<div itemscope>
 <p>My name is <span itemprop="name">yamada</span>.</p>
</div>

<div itemscope>
 <p>My name is <span itemprop="name">tanaka</span>.</p>
</div>

　上の例では、「"name"-"yamada"」と「"name"-"tanaka"」の二つのプロパティが作られます。 　上記の例では構文的な誤りはありませんが、せっかくMicrodataでマークアップしたデータを再利用することは出来ません。データを再利用するには、itemscope属性のitemtype属性（アイテムの型）を指定する必要があります。 　itemtypeはURLによって識別され、様々なアイテムが定義されています。itemtypeのURLとして、以下のURLが代表的です。

URL	説明
http://data-vocabulary.org	Googleの検索エンジンで用いられている
http://schema.org	GoogleやMicrosoftなどが共同で進めている構造化データ マークアップの共通仕様策定団体が定義するプロパティ

　http://data-vocabulary.orgの定義は、ほとんどがhttp://schema.orgに移行しましたが、パン屑リストに関してはhttp://data-vocabulary.org/Breadcrumbが効果的です。 　次はパン屑リストにhttp://data-vocabulary.org/Breadcrumbで定義されている型付きアイテムを適用した例です。

<ul>
  <li itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
  <a href="http://chiguhagunafugou.blogspot.jp/" itemprop="url">
  <span itemprop="title">ちぐはぐな符号 トップ</span></a> >
  </li>
  <li itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
  <a href="http://chiguhagunafugou.blogspot.jp/2016/12/syntaxhighlightersyntaxhighlighter.html" itemprop="url">
  <span itemprop="title">SyntaxHighlighterの設定</span>
  </a> >
  </li>
</ul>

HTML リスト（箇条書き）

　HTMLでは、次のようなリスト（箇条書き）を記述するためのタグが用意されています。

• item 1
• item 2
• item 3

　リストの記述では、リストの開始を終了を示すタグ（<UL>や<OL>）と個々の項目（要素）を示す<LI>タグを使用します。上記の例のコードは以下のようになります。

<ul>
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
</ul>

　OLタグは本来は番号付きリストの開始と終了を示すためのタグでしたが、HTML5では仕様が変更され、項目の先頭に固定文字を置いたり、項目だけを表示することもできるようになりました。これにより従来番号無しリストで使用していたULタグの必要性がかなり少なくなっています。 　リストの先頭の文字を「マーカー」と呼びます。マーカーはstyleのlist-style-typeプロパティによって設定します。 書式

<OL style="list-style-type: プロパティ値">

プロパティ値	マーカー	例
decimal	算用数字	項目 1 項目 2 項目 3
decimal-leading-zero	算用数字（先頭に0）	項目 1 項目 2 項目 3
lower-alpha	アルファベット小文字	項目 1 項目 2 項目 3
upper-alpha	アルファベット大文字	項目 1 項目 2 項目 3
lower-roman	ローマ数字小文字	項目 1 項目 2 項目 3
lower-greek	ギリシャ文字小文字	項目 1 項目 2 項目 3
disc	黒丸	項目 1 項目 2 項目 3
circle	白丸	項目 1 項目 2 項目 3
square	黒四角	項目 1 項目 2 項目 3
none	マーカー文字無し	項目 1 項目 2 項目 3
hiragana	あいうえお順	項目 1 項目 2 項目 3
katakana	アイウエオ順	項目 1 項目 2 項目 3
cjk-ideographic	漢数字	項目 1 項目 2 項目 3
hiragana-iroha	いろはにほへと順	項目 1 項目 2 項目 3
katakana-iroha	イロハニホヘト順	項目 1 項目 2 項目 3
armenian	アルメニア数字	項目 1 項目 2 項目 3
georgian	グルジア数字	項目 1 項目 2 項目 3
hebrew	ヘブライ数字	項目 1 項目 2 項目 3
lower-latin	ラテン文字小文字	項目 1 項目 2 項目 3
upper-latin	ラテン文字大文字	項目 1 項目 2 項目 3
initial	CSSで設定したデフォルトを適用
inherit	親要素のプロパティを継承

コード例

<ol style="list-style-type: upper-latin">
<li>項目 1</li>
<li>項目 2</li>
<li>項目 3</li>
</ol>

　list-style-imageプロパティを使えば、マーカーに画像を表示することもできます。

1. item 1
2. item 2
3. item 3

書式

書式１　<OL style="list-style-image: url(画像ファイルのURL)">
書式２　<OL style="list-style-image: inherit">
書式３　<OL style="list-style-image: none">

プロパティ値	意味
url(img)	imgに画像ファイルへのURLをセットするとリストの各項目の先頭に指定された画像が表示される
inherit	親要素のプロパティ値を継承
none	項目の先頭に画像を表示しない

使用例（コード）

<ol style="list-style-image: url(http://books-nekoya.jp/Programming/faviconPrg.png)">
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
</ol>

　reversed属性を使えば、リストの番号を逆順に表示することができます。

属性値	意味
"reversed"	リストの番号を逆順表示

表示例

1. item 1
2. item 2
3. item 3

　start属性を使えば、リスト番号の開始番号を指定することができます。

属性値	意味
n	リスト番号の開始番号

使用例（表示）

10. item 1
11. item 2
12. item 3

使用例（コード）

<ol start="10">
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
</ol>

HTML 文字参照と数値参照

　HTMLでは、それぞれの文字に割り当てられたエイリアス名やコードを使った「文字参照」や「数値参照」で文字を表現することができます。このような参照方法は、HTMLのテキストとして直接書けない<や>などの特殊文字などに用いられます。 　文字参照の書式は、次のように&にエイリアス名が続き、最後はセミコロンで終わります。

&name;

　数値参照には10進表記と16進表記があります。10進表記の場合は、&#にHTMLで定義された10進数の文字コードが続き、最後はセミコロンで終わります。

&#d;

　16進表記の場合は、&#xにHTMLで定義された16進数の文字コードが続き、最後はセミコロンで終わります。

&#h;

　HTMLにテキストとして直接書けない<や>などの文字は特殊文字と呼ばれ、以下のような文字が代表的です。

文字	文字参照	数値参照（10進）	数値参照（16進）	説明
<	&lt;	&#60;	&#x3C;	HTMLタグで使用
>	&gt;	&#62;	&#x3E;	HTMLタグで使用
半角スペース	&nbsp;	&#38;	&#x26;	連続する半角は1つにまとめられる
&	&amp;	&#160;	&#xA0;	HTMLでは文字参照で用いられる

　文字参照や数値参照では、記号文字も参照することができます。以下に使えそうな記号をピックアップしてみました。

文字	文字参照	数値参照（10進）	数値参照（16進）	説明
©	©	©	©	copyright
®	®	®	®	登録商標
™	™	™	™	商標
°	°	°	°	度
±	±	±	±
²	²	²	²	平方
³	²	³	³	立方
¼	¼	¼	¼	1/4
½	½	½	½	1/2
¾	¾	¾	¾	3/4
¿	¿	¿	¿	逆疑問符
♦	♦	♦	੪
♢		♢	੦
♥	♥	♥	♥
♡		♡	੥
♠	♠	♠	♠
♤		♤	੨
♣	♣	♣	੧
♧		♧	੫
♨		♨	੬
〽		〽	&#303D;	歌記号

文字	文字参照	数値参照（10進）	数値参照（16進）
Α	Α	Α	Α
Β	Β	Β	Β
Γ	Γ	Γ	Γ
Δ	Δ	Δ	Δ
Ε	Ε	Ε	Ε
Ζ	Ζ	Ζ	Ζ
Η	Η	Η	Η
Θ	Θ	Θ	Θ
Ι	Ι	Ι	Ι
Κ	Κ	Κ	Κ
Λ	Λ	Λ	Λ
Μ	Μ	Μ	Μ
Ν	Ν	Ν	Ν
Ξ	Ξ	Ξ	Ξ
Ο	Ο	Ο	Ο
Π	Π	Π	Π
Ρ	Ρ	Ρ	Ρ
Σ	Σ	Σ	Σ
Τ	Τ	Τ	Τ
Υ	Υ	Υ	Υ
Φ	Φ	Φ	Φ
Χ	Χ	Χ	Χ
Ψ	Ψ	Ψ	Ψ
Ω	Ω	Ω	Ω
α	α	α	α
β	β	β	β
γ	γ	γ	γ
δ	δ	δ	δ
ε	ε	ε	ε
ζ	ζ	ζ	ζ
η	η	η	η
θ	θ	θ	θ
ι	ι	ι	ι
κ	&lappa;	κ	κ
λ	λ	λ	λ
μ	μ	μ	μ
ν	ν	ν	ν
ξ	ξ	ξ	ξ
ο	ο	ο	ο
π	π	π	π
ρ	ρ	ρ	ρ
ς	ς;	ς	ς
σ	σ	σ	σ
Τ	τ	τ	τ
υ	υ	υ	υ
φ	φ	φ	φ
χ	χ	χ	χ
ψ	ψ	ψ	ψ
ω	ω	ω	ω

文字	文字参照	数値参照（10進）	数値参照（16進）
⇐	⇐	Ⅼ	&#21D0;
⇑	⇑	Ⅽ	&#21D1;
⇒	⇒	Ⅾ	&#21D2;
⇓	⇓	Ⅿ	&#21D3;
⇔	⇔	ⅰ	&#21D4;
←	←	←	ࢎ
↑	↑	↑	࢏
→	→	→	࢐
↓	↓	↓	࢑
↔	↔	↔	࢒
↖		↖	࢔
↗		↗	࢕
↘		↘	࢖
↙		↙	ࢗ
⇄		⇄	&#21C4;
⤴		⤴	୶
⤵		⤵	୷
⇦		⇦	⇦
⇧		⇧	⇧
⇨		⇨	⇨
⇩		⇩	⇩
⏎		⏎	⏎

文字	数値参照（10進）	数値参照（16進）
①	①	জ
②	②	ঝ
③	③	ঞ
④	④	ট
⑤	⑤	ঠ
⑥	⑥	ড
⑦	⑦	ঢ
⑧	⑧	ণ
⑨	⑨	ত
⑩	⑩	থ
⑪	⑪	&#246A;
⑫	⑫	&#246B;
⑬	⑬	&#246C;
⑭	⑭	&#246D;
⑮	⑮	&#246E;
⑯	⑯	&#246F;
⑰	⑰	দ
⑱	⑱	ধ
⑲	⑲	ন
⑳	⑳	঩

文字	数値参照（10進）	数値参照（16進）
○	○	&#25CB;
◯	◯	&#25EF;
⃝	⃝	&#20DD;
●	●	&#25CF;
◎	◎	&#25ce;
◉	◉	&#25C9;
⦿	⦿	&#29BF;
•	•	ߦ
◦	◦	&#25E6;

文字	数値参照（10進）	数値参照（16進）
‣	‣	ߧ
▲	▲	&#25B2;
△	△	&#25B3;
▴	▴	&#25B4;
▵	▵	&#25B5;
▶	▶	&#25B6;
▷	▷	&#25B7;
▸	▸	&#25B8;
▹	▹	&#25B9;
▼	▼	&#25BC;
▽	▽	&#25BD;
▿	▿	&#25BF;
◂	◂	&#25C2;
◃	◃	&#25C3;
►	►	&#25BA;
▻	▻	&#25BB;
◄	◄	&#25C4;
◅	◅	&#25C5;

文字	数値参照（10進）	数値参照（16進）
⃞	⃞	&#20DE;
∎	∎	&#220E;
■	■	&#25A0;
□	□	&#25A1;
▬	▬	&#25AC;
▭	▭	&#25AD;
▮	▮	&#25AE;
▯	▯	&#25BF;
▰	▰	&#25B0;
▱	▱	&#25B1;
◆	◆	&#25C6;
◇	◇	&#25C7;
◊	◊	&#25CA;
⧫	⧫	&#29EB;
〼	〼	&#303C;

　ASCIIコード領域の文字は、そのままASCIIコードを使って数値参照することができます。

ASCII

　上記はブラウザ上で、次の様に表示されます。

ASCII

アナリティクス アカウントのアカウント

　アナリティクス関連の記事を書いていて「アナリティクスのアカウントのアカウント」という表現がアナリティクスを使ったことのない人にはわかりにくいかも知れないことに気づきました。 　アナリティクスでは、一つのアナリティクスアカウントで複数のサイト（URL）を管理することができます。このそれぞれのサイト（URL）をアナリティクスでは「アナリティクスのアカウントのアカウント」と呼んでいます。このブログでは、「サイト」とか「URL」という言葉に置き換えた方がわかりやすいかなとも思ったのですが、そうするとアナリティクスのインターフェースやドキュメントとの整合性がなくなるので「アナリティクスのアカウントのアカウント」という表現を使っています。

アナリティクス アナリティクスアカウントへのアカウントの追加

(1) 「管理」タブをクリックして管理画面に移動する
(2) 管理画面のアカウント列の一番上のプルダウンメニューの最後にある「新しいアカウントを作成」を選択する

　管理画面では、アカウント名、ウェブサイトの名前、ウェブサイトのURL、業種、レポートのタイムゾーンなどを設定します。いくつかチェックボックスがありますが、画面上に説明がありますのでそれをご覧ください。通常はチェックのままでOKです。

　最後に画面最下部にある「トラッキングIDを取得」ボタンをクリックします。すると、アナリティクス利用規約への同意確認のダイアログが表示されますので「同意する」をクリックしてトラッキングコード画面に進みます。 　トラッキングコード画面では、次のようなトラッキングコードが表示されます。

htmlの場合、これをheaderタグ内に貼り付けます。phpの場合は、これを「analyticstracking.php」というファイルに保存して、それぞれのPHP テンプレート ページに挿入します。さらにそれぞれのテンプレートページのbodyの開始タグの直前に次の行を追加します。

<?php include_once("analyticstracking.php") ?>

ソフトウェア MultiReplace（クリップボード・複数ファイル置換対応の高機能置換ソフト）

　htmlにソースコードを張り付けたりする場合に<や>などのHTML特殊文字を&lt;や&gt;などのエスケープ文字に置き換える必要があります。これをすべて手作業でやるわけにはいかなので、せめてテキストエディターの置換機能を使って次のような手順で行っていました。
(1) コードを別のエディターウィンドウに貼り付ける
(2) 対象文字を全置換する
(3) htmlに貼り付ける
　こんな風に書けば簡単な作業に見えますが、(2)の置換作業には複数回のキーストロークやクリックが必要となり、これを置換対象の文字数分だけ繰り返す必要があります。うまく正規表現やマクロを使えば、一発で置換できるかも知れませんが、それを考えるのも面倒です。それでも何とかこのバカバカし作業を改善しなければと思っていました。 　そこで今回見つけたのが、MultiReplaceです。 　今回は、MultiReplaceを使ってhtmlのコードをhtmlに貼り付けられるようにタグの<や>を&lt;や&gt;に置換してみます。
　MultiReplaceはクリップボード置換に対応していますので、作業のために「新しいテキストエディターウィンドウを開く」という「美しくない作業」（バカバカしい作業）が不要となります。
　MultiReplaceは起動直後はファイル置換モードになっていますので、まずウィンドウの右上の「クリップボード」ボタンを押してクリップボード置換モードにします。
　次にウィンドウ左側に置換リストに置換前文字と置換後文字を次のような書式で書き込みます。

置換前文字/置換後文字

今回は次のように書き込みます。

</&<
>/&>

　あとはhtmlに貼り付けたいコードをクリップボードに貼り付けて、「置換」ボタンを押せば置換結果がクリップボードに書き戻されますので、それをhtmlに貼り付ければOKです。 　置換設定は保存することができますので、次回からはさらに作業が単純化できます。 　今回、HTML特殊文字置換のための見つけたソフトですが、他にもかなり機能が充実していて、ソースファイルの編集でも便利に使えそうです。MultiReplaceはvector.co.jpからダウンロードできます。

アナリティクス アカウントのアカウントの削除

(1) 削除したいアカウントにログインする

(2)「管理」タブをクリックして管理画面に移動する
(3) アカウント列の「アカウント設定」をクリックしてアカウント設定画面に移動する
(4) アカウント設定画面右上の「ゴミ箱に移動」ボタンをクリックする

　ゴミ箱に移動したアカウントは35日を経過すると完全に削除されます。それまでは、アカウント列の最後にある「ゴミ箱」アイコンから復活することができます。 　ウェブページのheaderタグなどに張り付けてあるアナリティクスのトラッキングコードを削除します。 トラッキングコード例

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-XXXXXXXX-1', 'auto');
  ga('send', 'pageview');

</script>