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が埋め込まれるようになります。