Warning: Declaration of FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Tags::wrap($content, $before, $sep, $after) should be compatible with FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Category::wrap($content, $sep, $parents) should be compatible with FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Post_Thumbnail::wrap($html, $post_id, $post_thumbnail_id, $size) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Post_Meta::wrap($data, $post_id, $key, $ui, $single) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Widget::wrap($params) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/widget.php on line 0

Warning: Declaration of FEE_Field_Comment::wrap($content) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Term_Field::wrap($content, $term_id, $taxonomy) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Single_Title::wrap($title) should be compatible with FEE_Field_Term_Field::wrap($content, $term_id, $taxonomy) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Option::wrap($content, $key, $ui) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0
Sabakura Blog - Part 2

Google XML Sitemapsで生成されるサイトマップの種類(xmlとgz)について

このブログを含めて、自分が管理しているサイトは原則としてGoogleのウェブマスターツール(WMT)に登録を行っています。あわせて、サイトマップの送信も行っています。

現在は管理しているサイトのほとんどがWordPressサイトになっているため、サイトマップの作成には有名なプラグイン「Google XML Sitemaps」を利用しています。

・Google XML Sitemaps – WordPress Plugins

ただ、このプラグインでは設定により「標準のXMLファイル(拡張子は.xml)」のものと「gz圧縮されたファイル(拡張子は.gz)」の両方を出力することができます。
※どちらかだけを作成することも可能です。

サイトマップファイルの生成

今まではあまり意識せずに両方を出力し、WMTにはgz形式のファイルを送信していましたのですが、ふと「どちらを送信するのが正しいのか?」「それとも両方送信するべきなのか?」「SEO上の効果に差はあるのか」などが気になったので調べてみました。

(もしかしてあまりに当たり前の情報だからなのかもしれませんが)意外とこのことに触れている記事が少なかったので、調べた結果を書いておきます。

gz圧縮について

まず「gz圧縮されたファイル」ですが、これについてはUnix/Linuxにおいて圧縮コマンド「gzip」を使った場合に生成されるファイルです。

このほかよく見られる圧縮形式として「.tar.gz」という形式がありますが、これは複数のファイルをgzipで圧縮したものです。サイトマップの場合は「sitemap.xml」のような単独のXMLファイルを圧縮するため、(.tarのつかない)「.gz」形式になります。

ためしにこのブログのサイトマップのサイズを確認してみたところ、以下のような結果になりました。たしかにgz形式のほうがサイズが明らかに小さくなっています。

  • sitemap.xml:18,342 byte
  • sitemap.xml.gz:2,440 byte

ウェブマスターツールへの登録について

では実際にWMTに送信するサイトマップの形式はどちらが望ましいかです。これについては、じつは「Google XML Sitemaps」の公式ヘルプに答えに近いことが書かれていました。

The “sitemap.xml.gz” is a compressed version of the “sitemap.xml” file. It has the same content, but is significantly smaller than the other one. This helps you and the search engines to save a lot of traffic. Since all search engines support compressed sitemaps, you actually don’t need the “sitemap.xml”, but maybe you or your visitors want to view them from time to time so keeping it doesn’t hurt.

要約すると「どちらの形式で作成しても中身には変わりないが圧縮されたgz形式だとサイズが小さいため、トラフィックの節約になる。すべてのの検索エンジンは圧縮したサイトマップを読み取れるので通常はgz形式で問題ない。ただユーザーが直接サイトマップファイルを閲覧するような場合には.xmlが役立つこともある」というわけです。

なおxml形式で送信したからといってインデックスが遅くなるなどのデメリットがあるというわけではないようです。なお、私は一時期「.xml」と「.gz」を両方ともWMTに送信していたことがありますが、とくに警告を受けたりSEO面で順位に変化も感じられませんでした。

ようするに、通常はサイズの小さいgz形式のファイルを送信していればOKということです。これで安心してサイトマップを送信することができるようになりました。

Notepad++でのSSH接続にはOpenSSH形式の秘密鍵を利用する

Windows用高機能エディタ「Notepad++」には、エディタ内から直接サーバーに接続してファイルの削除やリネーム、編集を行うことができるプラグイン「NppFTP」が付属しています。(参考:Notepad++のFTPプラグイン「NppFTP」の設定方法

じつはこの「NppFTP」では通常のFTP以外にも、FTPS(FTP over SSL)、さらにSFTP(SSH)にも対応しています。

しかし先日、契約しているVPSにSSH接続(公開鍵認証)で繋ごうとしたところ、下記のようなエラーが出て接続が行えませんでした。

[NppFTP] Everything initialized
Connecting
[SFTP] Host key accepted
[SFTP] Error during authentication: Invalid private key file.
Unable to connect

Disconnected

「Invalid private key file」という部分から察するに、どうも秘密鍵の認証が上手くいっていないようです。しかし、この秘密鍵は通常はSSHクライアントのPoderosaで問題なく認証が通っているファイルです。

で検索してみたところ、ある情報にたどりつきました。

If it says Invalid private key file, the key probably isn’t an OpenSSH key
・NppFTP not working via SSH – sourceforge

つまりNotepad++でのSSH接続には、秘密鍵がOpenSSH形式である必要があるとのことです。

Poderosaで使っている秘密鍵は独自形式のため、これをOpenSSH形式に変換する必要があります。変換については、Putty付属のツール「puttygen.exe」を用いるのがもっとも簡単だと思います。これについては以下の記事が参考になりました。

・poderosaの秘密鍵をOpenSSH形式に変換する – (゚∀゚)o彡 sasata299’s blog

上記記事の手順に従い、秘密鍵をインポートして変換後、メニューバーからOpenSSH形式でエクスポートすることで新しい秘密鍵が作成できます。
これを用いてNotepad++からの接続を試したところ、正常に認証がとおり接続可能となりました。

内部リンクだけでもGoogleペナルティは起こる&rel=”nofollow”での回避策

追記(2016年):現在も一定のアクセスをいただいているようなのですが、現在のGoogleにおいてはこの記事のペナルティ回避策は上手く働かなくなったように思います。(あくまで感覚的な話ですが)たとえnofollowをつけたとしても、それが内部リンクであれば通常のfollowリンクに近い形で認識されているように感じます。

※実体験を元にした情報ではありますが、SEOの専門家ではないためこの記事に書かれている推測が100%正しいと保証するものではありません。その点はご了承ください。

上記画像は私が管理しているサイト(このブログではないですが)のあるキーワードでの順位推移を示したものです。分かりにくいですが、三週間ほど150~250位を前後したあとに、いきなり5位前後まで上昇しています。

ペナルティ事例の解説

じつはこのキーワードは以前は2~5位で何ヶ月も安定していたのですが、ある日突然に大幅な順位下落を起こし、そのまま一ヶ月以上停滞していました。この現象は特定キーワードだけのものではなく、同サイトのほぼすべてのページが関連キーワードで100位以下~圏外まで飛びました。順位下落の状況としては「これってGoogleのペナルティなの?」に近いです。

自分としてはブラックハット的な施策は行っていないつもりでしたし、ウェブマスターツールにも警告メールが届いていないため、原因がまったく分からない状況でした。幸いにしてすでにリカバリは完了しているのですが、ペナルティにいたったと推測される要因があまり他のSEOブログでは見かけない情報だったため今回記事にしてみました。

※本来は「ペナルティ」という用語は、Googleとしての正式なものではありませんが、ここでは話を分かりやすくするために使用しています。

ちなみに画像は検索順位ツールである「GRC」のものです。本当は以前の安定していた頃の順位も見せれるとよいのですが、今回のペナを受けたことから導入を開始したため以前のデータがありません。

原因は内部リンクの数とアンカーテキスト

過剰な内部リンク

さて結論から書いてしまうと、(100%確実と断言できるわけではありませんが)おそらく原因は過剰な内部リンクにありました。

このサイトではとくにユーザーにとって価値が高いと思われるページに対して、様々なページの本文中から内部リンクを貼っていました。例としては以下のような感じになります。

ただしコスパ重視で選ぶなら商品Aもおすすめです。いくつかの面で商品Bに比べれば質は落ちますが、とても安価で気軽に購入できます。

上記はあくまでも例ですが、このような感じでいくつかのページの本文中から訴求したい商品Aに対して内部リンクを貼っていました。このときのアンカーテキストは「商品A」という商品名そのままを使っていました。

といっても、これはSEO的にページランクの受け渡しを狙ったわけではなく、単純にユーザーにとって最適な導線を提供しているだけのつもりでした。

なるべく良い商品を選んでもらえるようにすぐにページ移動できるようにしていたわけです。もちろん商品Aのみに集中させていたわけではなく、商品Bや商品Cなどにも、それぞれ状況に応じて同様の内部リンクを貼っていました。

内部のみでペナルティは発生しないのでは?

ここでSEOにある程度詳しい方であれば「内部リンクのみでペナルティは発生しないのでは?」と思うかもしれません。

実際「内部リンク ペナルティ」などで検索をすると「(昔のYahooは別として)現在のGoogleではまずペナらないのでさほど心配なし」といった記事が多く目に付きます。私も今までは、ヘッダやサイドバーへのキーワード詰め込みのような形でなければまず問題はないと考えていました。

しかし今回の体験談から言えば「内部のみでもGoogleのペナ発生はありうる」ことになります。しかも本文中からのリンクでも起こりえます。

リカバリ施策

半分ほどに減らすも反応なし

上記の「内部リンクが原因では?」に思い当たった時点で、対策をとることにしました。

素直に考えればリンクを減らすのが王道ですから、まず重要でないと思われるものを中心に全体の内部リンク数を半分ほどに削減しました。あわせてそのほか可能性として考えられる要因を修正した上で、Googleにサイトの再審査を依頼しました。

しかし返ってきたのは「手動対応は行っておりません」のメッセージのみでした。メッセージ到着から一週間ほど様子見をしましたが、順位変動もないため「リカバリ失敗」と判断しました。

rel=”nofollow”を付与

となると内部リンクをさらに減らすかですが、これ以上減らすと訪問してくれたユーザーにとっても不便になる可能性が出るため、できればその手はとりたくありませんでした。

そこで考えたのが「rel=”nofollow”」の使用です。もともとnofollowは信頼できないサイトに対して使用するものであり、「内部リンクにはnofollow属性を付けなくてよい」「自分のサイトのページを信頼していないし保証しないということになる」といった記事に見るように、内部に対して付与するものでないのは知っていました。

しかし「本当に内部リンクにrel=”nofollow”は不要なのか」の記事に見るように、あえてnofollowを使うことで、ユーザーを最適なページへ案内するために使う方法もありえます。

今回の事例で言えば「べつにページランクの受け渡しはゼロであってもかまわないが、ユーザーへの導線としてリンクは残しておきたい」と考え、そのためにrel=”nofollow”を内部リンクにつけることにしました。

そこでページランクが渡らないnofollowを、「商品A」や「商品B」でアンカーテキストを貼っている内部リンクのほぼすべてに付けてみました。結果として、4~5日後に見事に順位が回復しました。

本当に内部リンクが原因だったのか

順位が回復したとはいえ、これはアルゴリズム変更やそのほかの要因による可能性もあります。しかし、今回は高確率で内部リンクが原因だったと判断しています。根拠は以下の三点です。

  • このほかの疑わしい要素に対するリカバリ施策については、再審査を出した時点ですべて行っていた。しかし再審査後に一週間以上経っても順位にまったく変化は見られなかった。
  • その後、内部リンク施策のみ(nofollow化)を行ったところ、数日後にはっきりとした変化があった。
  • じつは同様のペナルティを受けている別サイトがあり、そちらでは内部リンクをすべて剥がす(nofollowをつけるのではなくリンクそのものを削除)という施策を同タイミングで行ったところ、このサイトとまったく同じタイミングで順位回復した。

このことから、内部リンクが原因であったこと、およびnofollowの付与がリンク削除と同じ効果を出したことが確認できます。

結論

長くなってしまいましたので、あらためて結論を書いておきます。

  • 本文からの内部リンクのみでも、数が多すぎたりアンカーテキストが最適化されすぎていると、(たとえそれがユーザーのためのものであっても)Googleの自動アルゴリズムによりペナルティを課せられる場合がある。
  • 対処法としてはリンクを剥がすのが王道だが、どうしても残しておきたいリンクの場合は「rel=”nofollow”」をつけることでも同様の効果が得られる。(ただし2012年12月現在の手法であり、また自己責任で行ってください)

今回のペナルティはSEO関連のブログなどにも既存の情報が少なくて原因を突き止めるのにも苦労しましたので、せっかくなのでここに情報を共有してみました。同じようなペナルティ状況で苦しんでいる方の一助になれば幸いです。