編集長の佐藤（@akihirosato1975）です。
ナビプラスでは今年3月に 公式サイト のリニューアルを行いましたが、それを機にいろいろSEO対策を行っています。
実際にはコンテンツ面の話がメインですが、それとは別に技術面でもいくつかチューニングをいくつか行っているので、今回はそれらをまとめて紹介したいと思います。
存在しないページについて、HTTP 404ではなく410を返す
まず手を付けたのがこれ。実は公式サイトのリニューアル直後、WordPressのプラグインとしては超定番とも言える All-in-One SEO Pack の設定をミスってしまい、Google先生に大量のゴミページがindexされてしまったという経緯があり、やむなく始めたという裏事情があります。
もっと具体的に言うと、WordPressではメディアライブラリに保存されている画像等について、その画像への直リンク以外にいわゆる「添付ファイルページ」というものが生成されますが、前述のSEO Packの設定で「サイトマップから画像を除外する（Exclude Images）」設定を行っていなかったためにその添付ファイルページが大量にindexされてしまったのです…。
当然気がついた段階でSEO Packのオプション設定はすぐに変更したわけですが、通常にHTTP 404を返すだけではなかなかindexが消えてくれないため、indexから情報が速やかに消えることを期待して添付ファイルページ（「is_attachment()」がtrueのページ）については410を返すように変更してみたわけです。
ついでにいろいろ調べていくと、「導入企業」や「ニュース」「セミナー」といったページで、後から追加したタクソノミー（taxonomy）による一覧ページがなぜかindexされている（本来そのようなページへのアクセスは想定されていない）ということも判明します。
そのため、それらについてもサイトマップから除くとともに、もしアクセスされた場合には同様にHTTP 410を返すようにしました（こちらの詳細はやや複雑なので省略）。
フロントのCloudFront化
続いて行ったのがCloudFrontの利用。実は今回のリニューアルに当たり、従来某データセンターのオンプレサーバ上で動いていたサイトをAWSに移行したのですが、ここで一つ困った問題が。
正直なところ、通常はt2.micro程度のインスタンスタイプでも問題なくアクセスがさばけるんですが、たまに共催セミナーの告知等を打ったときなど、特定のページがバズったときにアクセスが殺到してサーバ負荷が急上昇することがあり、それに対応するのが目的になります。
細かい設定はここでは省きますが、静的コンテンツ（CSS/JS/画像等）をCloudFrontに逃がせたため、Webサーバのヒット数が1/5ぐらいに削減でき、アクセス集中時でもとりあえずは問題なくさばける程度の負荷に抑え込むことができています。ただ社内のデザイナーから「CSSの変更の反映に時間がかかる」等の苦情も受けたので、CSSについてはTTLを短めに設定する等、パラメータ調整は随時行っている状況です。
データハイライターの利用
CloudFront化が一段落した段階で、次に行ったのが、Google Search Consoleにある データハイライター の設定。
データハイライターでは記事やイベント情報などのページを、Googlebotがクロールした内容を元に文書構造をGUIで設定できますが、今回は「ブログ」の記事と「セミナー」情報を同ツールを使って分析対象としました。
後述する構造化データの簡易版ともいえますが、プログラムがわからなくても比較的簡単に文書構造を設定できるので、その点ではおすすめです。
構造化データ
データハイライターの次は、やはりSearch Consoleにある 構造化データ の部分。
元々は冒頭に書いたゴミページの影響で、構造化データセクションについても大量のエラーが記録されてしまっていたため、それをなんとかできないかというところから調べ始めたんですが、いろいろ見ていくと、特にいわゆる「パンくず」の部分の対応が必要だということに気づいたわけです。
元々のページでも見た目のデザインとしてのパンくずは表示されていたんですが、よく調べていくと、実はGoogleのHTML Parserが構造化データとして認識できる形になってなかったことが判明しまして。
かといってHTMLを変更するとそれこそデザインが大きく崩れてしまうので、今回はschema.orgで定義されている BreadcrumbList をJSON-LD形式（「application/ld+json」）で導入するということにしてみました。
現在、だいたい200ページ強ほどにこのBreadcrumbListを設定してます。（ブログ記事はデータハイライターで構造が認識されるので、主にそれ以外のページ）
Open Graph Tags対応
ここまでやったところでしばらく様子を見ていたんですが、そのうちに出てきたのが「検索結果のsnippetに表示されるサマリが文字化けしている」という社内からのクレーム。
調べてみたところ、上記で導入したBreadcrumbListのデータがなぜかページ本文の一部として拾われてしまっているのが原因で、技術に明るくないユーザからは文字化けのように見えてしまっていたという状況でした。
とりあえずページ本文として拾われるのを防ぐために、BreadcrumbListのデータはページの極力末尾に近いところに置くように修正しましたが、それと合わせて、WordPressではおなじみ JetPack が生成する Open Graph Tags の中にJSONデータが拾われてしまっていたことも判明したため、そちらも修正しました。
といってもJetPackが生成する情報を管理画面から修正するのは難しそうだったので、結局functions.phpの中で強引に「og:description」「og:image」の2つを書き換えるという手法を取ってます。
結果
とここまでが技術面での対策となります。これに加えてコンテンツ系の対策も並行して行った結果、ゴミページをindexから減らしたため検索結果への表示回数は減少しましたが、CTRが大きく改善したほか、掲載順位も全体的に上昇傾向になってます。
ナビプラスは基本的にB2Bビジネスの会社なので、どうしても週末はアクセスやら掲載順位やらが落ちやすい傾向はあるんですが、それを加味してもかなり数値が良くなってきてる感じです。
SEO業界は日々いろいろな動きがあり、実際8月頭のGoogleのアップデートではナビプラス公式も結構な影響を受けましたが（いい部分も悪い部分も有り、結果的にはイーブンぐらい）、今後も技術面からSEOに対していろいろ対応できないかを検討していく予定です。