Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。詳細インデックス状況に変化はありませんでした。Google」を使用したインデックス送信も失敗してしまいました。この頃から、「クロールはされているが別の要因でインデックスされないのでは?」という疑問が湧きました。今回は、最後のクロール対策としてLPページに各LISTのEND-1へのリンクを設置し、LPに対してインデックス送信を行いました。詳細インデックス状況に変化はありませんでした。検証開始から3か月経過しましたが、インデックス状況に変化は見られません。ここまで来ると「クロールはされているが別の要因でインデックスされないのでは?」という、思いが強くなりました。クロール状況を確認するため、サーバーのアクセスログを集計してGoogleクローラーのアクセス状況を確認しました。当初は簡単な検証を行おうと思っていたため、アクセスログの目視チェックは検証項目に含めていませんでした。結果、クローラーは1か月に2~3回ほどEndページにアクセスしていたという事実が判明しました。実は最初にListがインデックスされた2014/11/06には、List-5,List-6のENDページをクロールしていました。「/list6/end/{{item.id}}」の形式のURLにもクローラーは度々アクセスしていましたが、List-5,List-6のENDに関してはすべてクロールされていました。List-4のENDに関しては上記と異なり、2015/01/08に初めて正常にクロールされました。2014/01/07に、List-4_End-1をインデックス送信したことがきっかけで、はじめてEndページのURLが認識されたと言えます。なると、インデクサの処理が失敗していることになります。そのため、HTMLやJavaScriptコードに問題がないか、という調査を行うことにしました。詳細インデックス状況に変化はありませんでした。クロールされているのにインデックスが行われない状況に疑問を感じたので、試しに「site:」コマンドではなく、各ENDのURLをGoogleで検索してみました。sitemap送信ページサンプルすると、インデックス確認できなかったENDページが検索結果に表示されました。上記のタイトルやスニペットの内容を確認すると、LISTページと同様の物が出ていました。最初は重複コンテンツ扱いになり検索結果画面に表示されていないだけかと思いましたが、ウェブマスターツールで確認してもインデックス数は0件でした。そのため、URLは判明しているがインデクサが止まっている特殊な状態だと判断しました。その結果を基に、重複と判断されるようなコードを確認したところ、OGPの設定内容がLIST、ENDで同一物になっていたことが判明しました。No5のアイテム一覧ページです。Mueller氏が「Web検索ではOGPを使用していない」とコメントしていたため、軽視していました。念のため、OGP削除後にLPに対してインデックス送信を行いました。予想としては、List-6のENDは引き続き重複コンテンツとみなされ表示されない可能性があります。List-4、List-5のENDはOGPを除外したことにより、コンテンツの重複判定が軽減され、正常にインデックスされる可能性があると判断しました。詳細ついにインデックス状況に変化がありました。List-4_End1のみインデックスに反映されました。×OGP削除の影響なのか、は定かではありませんが、コンテンツの重複解消が影響していると前提におき考察を進めました。Google」を使い直接インデックス送信を行っていました。Google」を使いインデックス送信を行わなければ、インデックスに反映されない可能性があると判断しました。この考察を基に最後の対策を行うことにしました。クロール施策を行っていないEndページである、List-4_End2、List-5_End2、List-6_End2を直接インデックス送信しました。Google」によるインデックス送信をしなければ検索結果に反映されないという結論がでます。した、List-4_End2、List-5_End2がインデックスに反映されました。×しかし、前回インデックス送信を行ったList-6_End-2はインデックスに反映されませんでした。List-6_End-2に関しては、リストと同様のコンテンツをHTML内に入れているため、コンテンツ重複と判断されていると予測しました。今回、List-4_End2、List-5_End2がインデックスされたことによって、私の中で1つの結論がでました。今回の検証の最終結果は、下記のようになりました。クローラーはアクセスしていた。普通にAngularJSを使いシングルページアプリを作成しても、一部ページはインデックスされません。下記の条件を満たせばHTMLSnapShotを使わなくても検索結果に反映できる可能性があります。今回の私のケースでは成功しました。html5Mode(pushState)。Google」を使い、画面レンダリング後インデックスを送信。OGPやHTMLなどが重複しないようにする。Google」を使い、手動でインデックス送信するのは現実的ではありません。小規模サイトであればともかく、動的にページが増える大規模サイトだと不可能と言えるでしょう。JavaScriptのインデックス処理に関しては現在成長中の段階と言えます。1か月足らずで状況が変わる可能性もあれば、1年後も状況が変わらない可能性もあります。Snapshot」を使うほうがよいでしょう。JavaScriptを活用したシングルページアプリではなく、純粋にサーバー側でHTMLを生成したアプリケーションを作ることをおすすめします。最後に今回のAngularJSを利用したSEO検証ではこのような結果がでました。SEOは環境によって大きく結果が左右されます。今回は単純なシングルページアプリケーションで試したため、このような結果が出ました。そのため、複雑なシングルページアプリケーションの場合、APIのセキュリティ対応でクローラーがAPIの結果を取得できず失敗してしまう可能性もあるでしょう。checking」やAPIのパフォーマンスの影響でレンダリングが失敗してしまう可能性もあります。今回の方法を使用しても環境によっては失敗してしまう方や、中には特に施策を行わなくてもインデックスされたという方もいると思われます。今回の話も一つの検証事例として参考程度に頭に入れていただければと思います。追記(2015年3月18日)2015年2月26日に発表された、スマートフォン向け検索でのランキングの変更についてがきっかけで、3月に入りインデクサの精度が変わった模様です。Google」を利用しなくても検索結果に表示されるようになりはじめてきました。シングルページアプリケーションのインデックスで苦労をせずに済む日も近いかもしれません。ショウヨウ)LINE株式会社に在籍しているフロントエンドエンジニア。LINE内Webアプリを担当。2002年からSEOの情報を趣味の一環として収集している。ApplicationをGoogleに認識させる為の検証を進めている。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。12:00法務担当者、6割超が今後業務で「生成AIを使用したい」と回答。12:00オルツ、日本語RAGでは軽量型LLMとして世界最高の精度と推論速度を達成した「LHTM-OPT2」をリリース新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。