ソフトウェアエンジニアのためのSEO
原文は Ben Hoyt により に公開されました。 このブログを購読する
数ヶ月前、私は社内のソフトウェア開発者向けに「エンジニアのためのSEO」というテックトークを行いました。SEOチームの私たちは、多くのエンジニアが検索エンジン最適化（SEO）についてあまり詳しくなく、コンシューマー向けページの設計がSEOの観点から最適とはいえないことが時々あると感じていました。
そこで、チーム全体で優れたSEOの基本を共有しておくことが役に立つと考えました。そして今、その内容を皆さんにも共有します。SEOについてはすでに多くの情報が公開されていますが、そのほとんどはSEO代理店によって書かれたものです。この記事は、エンジニアによって、エンジニアのために書かれています。
昔と今
数年前と比較して、現在のGoogleの検索結果ページがどう変わったか見てみる価値があります。
2012年当時は画面が小さかったにもかかわらず、スクロールせずに3件の自然検索結果が表示されていました。2019年には、4件の広告に加え、Googleナレッジグラフの項目や「他の人はこちらも質問」といった回答が並び、その後にようやく1件の通常の検索結果が表示されるだけです！
スクロールせずに見える範囲に表示されること自体がどんどん難しくなっており、優れたSEOの重要性はむしろ増していると言えるでしょう。
SEOとは何か
SEOは「search engine optimization（検索エンジン最適化）」の略です。検索結果でページの順位を上げ、検索エンジンからのトラフィックをより多く、より質の高いものにするための施策を指す、少しかしこまった言い方です。
Googleが主要な検索プロバイダーであるため、これは実質的にGoogle検索で上位に表示されることを意味します。ただし、Googleのために行うべきことのほとんどは、他のすべての検索エンジンにとっても有効です。
なお、SEOはSEM（search engine marketing、検索エンジンマーケティング）とは異なります。SEMはキーワード連動型広告にお金を払うことに関するものです。SEOの「O」はオーガニック、つまり非有料の検索、「M」はマネー、つまり有料の検索を意味すると考えると分かりやすいでしょう。この記事ではSEMは扱わず、SEO、特にインデックスされる方法と上位表示させる方法に焦点を当てます。
SEOの中にはエンジニアにとって比較的シンプルな部分（主に技術的な事柄）もあれば、はるかに難しい部分（実際に良質なコンテンツを作り、公開すること）もあります。ここでは主に、前者のシンプルで技術的な最適化に焦点を当てます。
クロールとインデックスを確実にする
ページに最低限必要なのは、Googlebotにクロールされ、インデックスされることです。驚くほど簡単にここで失敗してしまいます。検索順位を上げたいページやページタイプは、それぞれ次の条件を満たしている必要があります。
- robots.txtで許可されている
- 安定した正規URLを持っている
- HTTP 200を返し、404や500ではない
- サーバーサイドレンダリングされたHTMLを使っている
- サイト内からリンクされている
- XMLサイトマップに含まれている
それぞれについて、もう少し詳しく見ていきましょう。
Robots.txt
中規模から大規模なサイトのほとんどは、/robots.txtにテキストファイルを設置しています。このファイルは、Googleのウェブクローラーのような「善良なボット」に対して、どのページをクロールすべきか、すべきでないかを伝えるものです。ファイル形式は非常にシンプルで、詳細はrobotstxt.orgやGoogleのドキュメントで解説されています。シンプルなrobots.txtの例は次のようなものです。
Sitemap: https://www.example.com/sitemap.xml
User-Agent: *
Disallow: /api/
Disallow: /staff/これはGooglebot（および他のクローラー）に2つのことを伝えています。
- このサイトのXMLサイトマップはここにあります。
- すべてのユーザーエージェント（つまりすべてのクローラー）に対して、/api/ または /staff/ で始まるURLはクロールしないでください。
ただし、少し注意が必要です。たとえば、SEOやこの記事の内容をよく知らない善意のエンジニアが「鬱陶しいボットを全部ブロックしてやろう」と考えて、ファイルに「Disallow: /」を追加してしまったらどうなるでしょうか？
あるいは、CEOから開発者に「私についてのページを作ってくれ」と依頼があり、開発者がrobots.txtのルールを知らないまま、ページを/staff/billgに設置してしまったらどうでしょう。そのページがインデックスされる可能性がまったくないことに、誰も気づかないかもしれません。
このようなことは、思っている以上によく起こります。一部の企業では、robots.txt解析ライブラリを使って、重要なページが常にクロール可能であることを保証する自動チェックを導入しています。少なくとも、robots.txtはバージョン管理下に置き、すべての変更を徹底的にレビューすべきです。
当然ながら、クロールさせたいページはrobots.txtで許可しておく必要があります。一方で、クロールする必要のないURLは積極的にブロックすべきです。たとえば、JSONのAPIレスポンスはクロールされるべきではありません。Googleはサイトごとに割り当てるクロールバジェットに限りがあるため、不要なものまでクロールさせたくないからです。
なお、robots.txtでページをブロックすることは、決してセキュリティ対策にはならないことに注意してください。悪意のあるボットやハッカーは依然としてそれらのページをクロールできます。そのため、たとえばrobots.txtでブロックされている/api/へのリクエストであっても、その背後にある情報が公開情報でない限り、適切な認証で保護する必要があります。
安定した正規URL
既存のウェブアプリを扱っている場合、URL構造はすでに決まっているかもしれません。しかし、新しいURLを設計する際には、次の点を心に留めておいてください。
1ページ1URL：常に1つのページを1つの正規URLから配信してください。ここで言う正規（canonical）とは、rel=canonicalリンクのことではなく、正規化された単一のURLを指します。たとえば、/staff/billgでページを配信しているなら、同じ内容を/staff/gates/billでも配信しないでください。複数のURLを許可したい場合は、他のURLから正規のURLへ301リダイレクトするようにしてください。
末尾のスラッシュを統一する：上記に関連しますが、/staff/billgと/staff/billg/の両方でHTTP 200を返さないでください。どちらか一方を正規URLとして選び、もう一方からはそちらへ301リダイレクトするようにしてください。
ある程度可読なURLにする：URLに説明的なキーワードを含めることを推奨する文献は多く、それは「モダンなウェブ」のベストプラクティスとなっています。たとえば、/articles/1234よりも/articles/1234/seo-for-engineersのようなURLの方が好ましいです。
リソースIDを含める：上の例のように、URLに1234のようなリソースIDを含めておくと技術的にシンプルになります。IDを使って実際にリソースを検索し、「seo-for-engineers」のスラッグが記事の現在のスラッグと一致しない場合は正規URLへ301リダイレクトしてください。StackOverflowやTripAdvisorをはじめとする多くのサイトがこの手法を採用しています。過去のURL変更やリダイレクトのデータベースを保持する必要がなくなるためです。
ウェブアプリのURL構造があまりにも悪く、再設計が必要な場合でも、安全に実現することは可能です。古いURLから新しいURLへHTTP 301 Moved Permanentlyでリダイレクトする必要があります。ただし、これを頻繁に行うのは避けてください！
301を必ず使うべき場面の1つは、http://サイトからhttps://サイトへのリダイレクトや、wwwなしドメインからwwwありドメイン（またはその逆）へのリダイレクトです。
クリーンなHTTPレスポンス
Googlebotから見て、ページをできるだけクリーンに見せたいところです。リダイレクトなしでHTTP 200を返すのが理想です。そうすることで、Googleが再試行でクロールバジェットを無駄にしたり、最悪の場合、リンク切れや断続的な500エラーのせいでページの順位が下げられたりするのを防げます。避けるべきものは次のとおりです。
- HTTP 404：URLが誤って404 Page Not Foundを返している場合、リンクが壊れているか、ページハンドラーに不具合があるかのどちらかです。いずれも避けるべきです。もちろん、その場所にページが存在すべきでない場合は、404を返すのが正しい挙動です。
- HTTP 301：301 Moved Permanentlyは有用で重要な役割を果たします（前節を参照）が、サイト内のページが大量のリダイレクトURLにリンクしている場合は、それらのリンクを更新すべきです。
- HTTP 500：Internal Server Errorは、Googleから見てページが完全に壊れていることを意味します。エンジニアであれば通常500エラーをしっかり監視しているはずですが、もしそうでないなら、今すぐ始めるべきです！
詳細については、MozのHTTPステータスコードガイドを参照してください。
サーバーサイドレンダリング
検索されることが重要なページについては、常にサーバーでレンダリングされたHTMLを配信すべきです。これはユーザーにとっても（読み込みが速く、JavaScriptの実行によるバッテリー消費も少なくて済む）、Googlebotにとっても有益です。
「でも、Googleは今やJavaScriptを実行するじゃないか」と言う人もいるでしょう。確かに少なくとも2014年以降、GoogleはJavaScriptを実行してページをよりよく理解しようとしています。しかし、単にHTMLを解析するのに比べてJavaScriptを実行するのはおそらく桁違いに困難です。サーバーサイドレンダリングされたHTMLからテキストを解析するのに比べ、V8を起動してJavaScriptを実行するのにどれだけ多くのCPUパワーが必要になるかを考えてみてください。
JavaScriptの実行をGoogleに頼ることには多くの注意点があります（上記2014年の記事を参照）。さらに、GoogleはHTMLは瞬時に解析する一方で、JavaScriptの実行は2段階のプロセスであり、大幅に遅延する可能性があります。したがって、最良の結果を得るためには、常にサーバーで生成されたHTMLでコンテンツを配信してください。
Reactのようなクライアントサイド技術を使ってページをインタラクティブにすることは依然として可能です。ただ、少し手間をかけてサーバーサイドレンダリングを有効にする必要があります。Compassでは数年前にクライアントサイドのReactからサーバーサイドレンダリングに切り替えた際、順位が大幅に改善しました。
ReactDOMServer.renderToString(element)React要素を初期HTMLとしてレンダリングします。ReactはHTML文字列を返します。このメソッドを使えば、サーバー上でHTMLを生成し、初期リクエストでマークアップを配信できるため、ページの読み込みが速くなり、検索エンジンがSEO目的でページをクロールできるようになります。
内部リンク
「内部リンク」はSEOのバズワードですが、単に同じサイト内のあるページから別のページへのリンクを意味します。こうしたリンクはユーザーがサイト内を移動するのを助けるだけでなく、Googleがサイトをクロールするのを助け、「ランキングパワー」をサイト全体に行き渡らせる効果もあります。詳細は内部リンクに関するMozの記事をご覧ください。
内部リンクは通常、比較的簡単に実現できます。重要なページから他の重要なページへ、（常識の範囲内で）できるだけ多くリンクを張るようにしてください。内部リンクの例としては次のようなものがあります。
- パンくずリスト
- ヘッダーやフッターのナビゲーションリンク
- ユーザーの回遊を助け、Googlebotが追加のページを見つけやすくするリンクブロック。たとえば、Compassの物件ページから類似物件へのリンクなどです。
大規模なサイトのほとんどは、サイト上の重要なページすべてへのリンクを含むHTMLサイトマップも用意しています。以前はユーザーにとってより有用でしたが、今ではサイト内検索が普及したことで、SEOツールとしての側面が強くなっています。とはいえ、HTMLサイトマップを用意することは今でも良いプラクティスとされています。
Compassをはじめとする不動産サイトには、州、郡、郵便番号の階層構造を持つHTMLサイトマップがあり、末端のページからは現在有効なCompassの独占物件すべてにリンクしています。これも物件ページをGoogleに露出させるための一つの方法です。
XMLサイトマップ
Compassのような大規模なウェブサイトにとっては、おそらくXMLサイトマップの方がより重要です。これらは、Google Search Consoleにアップロードするかrobots.txtで参照される、サイト上のすべてのURLを単にリストアップしたシンプルなXMLファイルです。これにより、Googlebotは数千ものリンクをたどることなく、すべての商品ページを体系的に見つけることができます。
Compassは複数のXMLサイトマップを用意しています（サイトマップは複数持つことができます）。
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-sf/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-la/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-nyc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-dc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-other/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/rentals/index.xml
...各sitemap index.xmlは、実際のsitemap.xmlファイルへリンクするファイルで、その中身は次のようになっています。
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>
https://www.compass.com/listing/101-old-mamaroneck-road-unit-1b4-white-plains-ny-10605/409187998570262817/
</loc>
<lastmod>2020-02-22T01:25:55.877000+00:00</lastmod>
</url>
<url>
<loc>
https://www.compass.com/listing/4641-south-lincoln-street-englewood-co-80113/414572085652655249/
</loc>
<lastmod>2020-02-22T01:25:16.710000+00:00</lastmod>
</url>
...「lastmod」フィールドは任意ですが、Googleがそのページの情報が最後にいつ更新されたかを知り、再度クロールすべきかを判断するのに役立ちます。
詳細はGoogleドキュメントのXMLサイトマップについての解説をご覧ください。
パフォーマンスを高め、より上位に表示されるために
ページ内の基本
個々のページを発見されやすくするために行うべき基本的なことはさまざまあります。
- ページはモバイルフレンドリーであるべきです。Googleはモバイルファーストインデックスを採用しているため、モバイルデバイスで非常に快適に動作するようページを最適化すべきです。また、モバイルとデスクトップで異なるコンテンツを配信しないでください。これらの対応はGooglebotだけでなく、ユーザーにとっても有益です。
- 各ページには簡潔で具体的な<title>タグが必要です。これはGoogleがページの要点を理解するのに役立ち、通常は検索結果ページで目立つ形で表示されます。
- 各ページには簡潔かつ正確な要約をmeta descriptionとして記述してください。meta descriptionに関するMozのドキュメントを参照してください。
- 各ページは適切な構造を持つべきです。意味のある<h1>や<h2>見出し、意味のあるリンクテキスト、適切なaltテキストを持つ画像などです。
- 商品ページなどでは、構造化データ（JSON-LDなど）を使ってGoogleにより詳細な情報を提供してください。これはGoogleがコンテンツをより詳細に理解するのに役立つだけでなく、たとえば次のような検索結果ページの情報ボックスを表示するのにも使われます。
ページの表示速度
2018年、Googleはモバイルページのランキング決定要因としてページの表示速度を利用するようになったと発表しました。そのため、ページを高速化することは十分に価値があります。
もちろん、まず重要なのはバックエンドのHTMLがタイムリーに返されることです。これは測定が容易ですが、あくまで第一歩に過ぎません。クライアントサイドのパフォーマンスも考慮されます。Googleはページ速度の測定と改善方法について多くの情報を公開しているので、ぜひ目を通すことをお勧めします。
また、ChromeにはGoogleの視点でページ速度をローカルで測定できる優れたツールが標準で搭載されています。ページ上で右クリックして「Inspect」をクリックし、「Audits」タブで「Performance」監査をMobileで実行してみてください。いくつか（時には役立つ）提案を含む、見栄えの良いレポートが得られます。
スピードに関するGoogleの記事は、同社の速度テスターで90/100点を獲得しています。なかなかの高得点です（それとも出来レースでしょうか？:-）。
ページの表示速度には多くの要素が関わっています。
- Time to first byte：サーバーが最初の1バイトを返すまでにかかるネットワーク時間です。その後、ユーザーの帯域幅とHTMLのサイズに依存するHTMLのダウンロード時間が続きます。サイズは小さく抑えましょう！
- First contentful paint：DOMからの実際のコンテンツを含む最初のレンダリングまでの時間です。これによりユーザーに何かが起きていることを示せ、Googleもページ速度のシグナルの1つとして利用しています。
- Time to interactive：ユーザーが実際にページを操作できるようになるまでの時間です。通常、ページが操作可能になるにはある程度のJavaScriptの実行が必要なため、JavaScriptバンドルのサイズや起動時間などに注意してください。
- Static assets：CSSやJavaScriptは、できればCDNの背後で、長い有効期限でキャッシュされるべきです。また、可能な限り小さくしておく必要があります。Moment.jsのような巨大なJavaScriptパッケージには注意してください！
- Image load time：適切なキャッシュヘッダーを伴い、できればキャッシュ用CDNの背後で、適切なサイズの画像を配信すべきです。ページが多数の大きな画像を参照している場合は、一部の画像を遅延読み込み（lazy-load）することを検討してください。
注意してください！多くの企業と同様、あなたも常にページを反復的に開発・改善しているなら、ページはおそらく徐々に遅くなっています。新しい機能やバックエンドサービスへの追加の呼び出しを追加する際など、継続的にページ速度を測定し、警戒を怠らない必要があります。
リンクとドメインの権威性
GoogleはPageRankアルゴリズムから生まれました（奇妙なことに、これはウェブページではなくラリー・ペイジにちなんで名付けられています）。
PageRankは、あるページへのリンクの数と質を数えることで、そのウェブサイトがどれだけ重要かをおおまかに推定する仕組みです。
言い換えれば、他の多くのページがあなたのページにリンクしていれば、順位は上がりやすくなります。そしてそれらのリンク元が高いPageRankを持つページであれば、さらに効果的です。そのため、権威あるウェブサイトからできるだけ多くリンクしてもらうことが望ましいのです。
この例外がrel=nofollowリンクです。「nofollow」は、サイトが<a>リンクタグに追加して、Googleにこのリンクをたどったり、ランキング計算に含めたりしないよう伝える属性です。これは通常、質が低くスパムになりがちなブログやYouTubeのコメントのようなユーザー生成コンテンツに使われます。
もしこのようなサイトがrel=nofollowを使わなければ、スパマーは自身のページへのリンクを何百も投稿して、順位を不正に押し上げようとするでしょう。そして、まさにそれが「nofollow」導入以前に起こっていたことなのです。
また、ドメインオーソリティと呼ばれるSEOの概念もあります。これは特定のドメインが全体としてどれだけの権威を持っているかを示すMozの指標です（たとえば、nytimes.comは100点満点中95点、stackoverflow.comは93点、私の小さな個人サイトは37点です）。これはGoogleの指標ではありませんが、Googleが特定のドメインをどれだけ重要と見なしているかの妥当な目安になるようです。
さらに読む
この記事では主に、エンジニアが直接コントロールできることが多い技術的なSEO改善について述べてきました。しかし、これは物語の半分に過ぎません。
これらの技術的なSEO対策をすべて行っても、良いコンテンツがなければGoogleは上位に表示してくれず、誰もあなたのサイトを使わないでしょう。優れたSEOも、ひどいコンテンツと組み合わさっては悪いSEOでしかありません。一方で、良いコンテンツがあれば、これらの手法に従うことで上位表示される可能性を大いに高めることができます。
本家Googleが提供するSEOスターターガイドは、これらのトピックについて素晴らしい読み物です。Mozの初心者向けSEOガイドも同様におすすめです。
連絡を取りたい場合は、robots.txtの上部にあるバナーをご覧ください！
コメント
ログインしてコメントする