上級SEO対策ガイドライン
上級SEO対策ガイドラインは全部で以下のような6コンテンツで構成いたします。ご自身に必要な記事をご確認ください。
シンプルな URL にする
この記事を読まれている読者層の中には既に対応されている方も多いとは思いますが、URLは可能な限りシンプルであることが望まれます。
そのためにはサイトマップを正しく作成し、人の目で見ても論理的にわかりやすい構成にする必要があります。
例えば、次の2つのURLを見れば構造的にわかりやすいURLとわかりにくいURLが見て取れるはずです。
- 例1.https://www.example.com/seo/how-to-plan-seo-contents/
- 例2.https://www.example.com/index.php?id=13dfg1f3f516&sid=12141915io
例1はURL構造として人間の目でもわかりやすくなっています。「seo」という大カテゴリの中に「how-to-plan-seo-contents」という記事があることがわかり、さらにスラッグからどのようなコンテンツであるのかの予測もつきます。
例2ではIDを使ってURLを作っているため複雑であり、人間の目で理解することは難しく推奨はできない方法です。IDなどを使って動的にURLを発行してしまうとサイト上に類似したコンテンツが存在しているかのように見えたり、同一コンテンツに対して複数のURLを発行することになりかねません。
これはGoogleがクロールするのに必要以上に時間をかけることに繋がり、結果的にインデックスされないページが出てくる可能性があります。いわゆるクロールバジェットの無駄遣いに繋がります。
また、URLで単語をつなぐ際には_(アンダースコア)ではなく、-(ハイフン)を使うことをGoogleが推奨しています。
なぜ複雑なURLになるのか
URLが複雑になる理由はさまざまですが、以下のような原因が考えられます。
- 複数の検索フィルタをURLに組み込んでいる場合
- コンテンツの動的生成
- セッションIDによるURL生成
- 検索フィルタを複数の並べ方で表示する場合
- URLに参照パラメータを用いた場合
- 開始日と終了日のないカレンダーを使用している場合
- 破損した相対リンク
基本的に静的なサイトを作っていれば複雑なURLにはなりづらいはずですが、大型サイトやECサイトなどではIDやパラメータを使ってURLを生成することが多くなりがちです。
複数の検索フィルタをURLに組み込んでいる場合
同じ検索結果を複数の方法で表示できるサイトや検索フィルタを足し合わせてURLを生成するサイトの場合、内容にほとんど差のないページのURLが大量に発行されることになります。
このケースについてGoogleでは次のような例を挙げています。
http://www.example.com/hotel-search-results.jsp?Ne=292&N=461
http://www.example.com/hotel-search-results.jsp?Ne=292&N=461+4294967240
http://www.example.com/hotel-search-results.jsp?Ne=292&N=461+4294967240+4294967270
いずれもページとしては同じであるもののURLが異なっているため複雑なURLになっています。
コンテンツの動的生成
パラメータによりコンテンツの内容が変化する場合などがこれに該当します。コンテンツを動的に生成する場合で内容がほとんど変わらない場合には注意が必要です。
セッションIDによるURL生成
セッションIDをURLに使う場合にはまったく同じページであっても大量のURLを発行することがあります。cookieを無効にしているユーザーのためにセッションIDをURLに用いることはありますが、セキュリティ的には望ましいことではなく、改良の余地があります。
検索フィルタを複数の並べ方で表示する場合
大型ECサイトなどでは同一の商品が検索されて並べる際のURLに複数の条件を使うことがあります。これにより大量のURLが発行されることが起こり得ます。
URLに参照パラメータを用いた場合
サイトへ流入したユーザーの参照元をGAなどの分析ツールで特定するためにURLに参照パラメータを用いることがあります。参照パラメータを用いることに問題はありませんが、不必要に増やすべきではありません。
開始日と終了日のないカレンダーを使用している場合
例えば、カレンダーをURLのパラメータで動的に作る場合に開始日と終了日がなければ大量のページを生成できてしまいます。このような事態は避けるべきです。
破損した相対リンク
相対リンクが破損し、しかもそれが繰り返される場合には想定していなかったURLになることがあります。リンク切れのチェックはもちろんですが、破損した相対リンクを作らないためにも絶対パスやルートパスを検討してください。
複雑なURLを回避する方法
複雑なURLを回避するには次のような方法があります。
- robots.txtでGooglebotのアクセスを制御する
- セッションIDの代わりにCookieを使う
- 不必要なパラメータを排除する
- nofollowを活用する
- 破損した相対リンクをなくす
robots.txtでGooglebotのアクセスを制御する
robots.txtを使い検索結果を生成するURLなどの動的にURLへのアクセスをブロックすることで大量のURLが生成されることを防ぐことができます。
多くの場合、正規表現を使うことで少ない手間で解決することができます。
セッションIDの代わりにCookieを使う
セッションIDをURLに用いることはセキュリティの観点で望ましくありません。可能であればCookieを使ってください。(hiddenフィールドを利用する方法もあります。)
不必要なパラメータを排除する
パラメータは短ければ短いほど望ましいため、可能な限り不必要なパラメータを削除するように設定してください。
nofollowを活用する
動的に生成されるカレンダーなどのページへのリンクにnofollowを使うことでクロールがスムーズになります。
破損した相対リンクをなくす
破損した相対リンクがないようにすることで解決できますが、一度作成したサイトから破損した相対リンクを見つけることは容易ではありません。
URLには絶対パスを使うか、ルート相対パスを使うことで解決できることがほとんどですのでご検討ください。
外部リンクの関係性を伝える
サイトには内部リンクと外部リンクの2種類があります。自身のサイト内の回遊を促す内部リンクであれば特別な設定は必要なく、アンカータグ<A>を使うことでリンクできます。
しかし、外部への発信するリンクについては状況次第ではrel属性を利用する必要があります。一般的な外部リンクについては内部リンク同様にアンカータグ<A>だけでリンクできますが、特殊な発リンクには以下の4種類のいずれかをご利用ください。
- rel=”nofollow”
- rel=”sponsored”
- rel=”ugc”
- 上記3つの組み合わせ
なお、内部リンクで上記nofollow、sponsored、ugcの3つの属性を使うことはほとんどありません。これらを使うことで正統な評価を受けられないことがありますのでご注意ください。
※nofollowの反対をdofollowと言いますが、初期設定はdofollow(rel=”follow”)になっているいため、あえて設定する必要はありません。
rel=”nofollow”
リンクとリンク先のサイトを関連付けたくない場合にはアンカータグ<A>にrel=”nofollow”属性を使うようにしてください。nofollowを使うことで外部リンク評価をさせないことができます。ただし、次に示すsponsoredまたはugcが使える場合にはそちらを優先する必要があります。
外部リンクにnofollowを使うか使わないかには議論の余地があります。実際、WEB業界では外部への発リンクに対してnofollowを使うべきではないという発言をしている人もいます。nofollowを使うことは外部リンク評価をさせないことになりますが、外部のサイトを紹介している時点で評価すべきという意見があるためです。
しかし、外部リンクを貼ることで良くない事例や悪意のあるサイトであることを紹介している場合などにもプラス評価されてしまうという問題があります。
nofollowは名称の通り「フォローしない」という意味ですので、プラス評価すべきではないサイトを紹介しているような特殊な状況以外(特にSEO効果を操作するためだけに)利用すべきではありません。
rel=”sponsored”
広告や有料リンクを使っている場合にはnofollowではなく、rel=”sponsored”を使います。名前の通り「スポンサー」ですので広告であることをGoogleに明示できます。
※sponsoredと次に紹介するugcの2つは2019年9月頃から使われるようになっていますので、それ以前に貼った外部リンクは正しく設定していればnofollowになっているはずです。しかし、nofollowになっているものを後からあえてsponsoredまたはugcに変更する必要はありません。
rel=”ugc”
UGCとはuser generated contentの略で、ユーザーが作ったコンテンツのことです。そのため、rel=”ugc”は多くの場合、コメントに貼られたURLについて使われる属性となっています。
もしコメントスパムが想定される場合にはugcを使うだけではなく、投稿されないような措置を取る必要もあります
。
子供向け取り扱いサイトのタグ付け申請
日本ではほとんど知られていませんが、児童オンラインプライバシー保護法(COPPA:The Children’s Online Privacy Protection Act)というアメリカの法律があり、13歳未満の子供がネット上で収集したコンテンツは保護者が管理することができるようになっています。
このCOPPAへの対応を目的として、子供向けサイトに対してタグ付けすることでGoogleに対して子供向けのサイトとして申請することができます。
COPPAはアメリカの法律であり、タグ申請をすることで検索順位に影響することはないため、通常気にする点ではありませんが、アメリカに進出する場合にはご検討ください。
なお、Googleは子供向け取り扱いのタグについて以下の注意点を挙げています。
- 子供向けとして取り扱うようドメインの全体または一部(サブドメインまたはサブディレクトリ)をタグ付けできます。
- ドメインやディレクトリの下位のページもタグの対象となります。
- この指定が該当する Google サービスに適用されるまでには、時間がかかることがあります。
- Google は、指定できるドメインまたはサブドメインの数をいつでも制限できるものとします。
ブラウザの互換性を考慮する
あらゆるサイトはブラウザを通して表示されることを前提としています。つまり、ブラウザで表示できないようなサイトや構成は正しいサイト運営を行っているとはいえません。
ブラウザの互換性を確認するには次の4つの点で検討してください。
- ブラウザの表示テストをする
- 正しいHTMLでサイトを作る
- 文字エンコードを設定する
- ユーザー補助を考慮する
ブラウザの表示テストをする
サイトを作成したり、リニューアルした際には必ず実機でブラウザの表示テストを行ってください。Chrome、Edge、safariの3つだけで動作確認をしているWEB制作会社は多くありますが、これ以外にもIE、firefox、Operaなどのブラウザを使っている可能性もあります。
スマホではiPhone5などは2021年の時点でも使われているため、どのようなユーザーのアクセスがあっても正しく表示されるよう確認すべきです。
正しいHTMLでサイトを作る
tableで作っているサイト、frameで作っているサイトは現在では非常に少ないが、それでも存在はしています。しかし、そのようなタグでサイトを作ることは正しい運用とは言い難く、動作が保証されているものではありません。
仮に現時点で問題なく動作していたとしても、将来にわたって正しく動作する保障はなく、HTMLがマークアップ言語であることを考えれば仕様を確認した上で正しいHTMLでサイトを作るべきです。
なお、SEOを考えた場合にどのようなHTML表記が正しいのか(効果が出るのか)という疑問を持たれる方がいますが、SEOを基準に考えた場合に優れたHTMLというものは存在しません。タグの意味を考え、無駄のないHTMLコーディングが望まれます。
文字エンコードを設定する
現在では文字エンコードが指定されていないために文字化けを起こすという現象は非常に少なくなりましたが、文字エンコードは設定することが推奨されています。
HTML5ではUTF-8が推奨されていますので <meta charset=”utf-8″> が指定されていれば問題ありませんが、UTF-8以外にもシフトJISやEUC-JPなどの文字コードが使われることもあります。
ユーザー補助を考慮する
動作環境は人によってそれぞれです。ほとんどの場合ではHTML、css、javascriptが正常に動作することが前提になっていますがjavascriptが必ずしも動くとは限りません。Flashは現在では推奨されておりませんし、Active Xが動作することを前提でサイトを作らないということも重要です。
重複コンテンツを避ける
サイトが肥大化していくにつれ類似コンテンツが増えていくことがあります。多少似ている部分がある程度であれば問題ありませんが、同じことを言っていると判断されるようなページがあることはマイナスになります。
このような重複コンテンツが発生しないためには以下のことを気を付けてください。
- 301リダイレクトを利用する
- 内部リンクの形式を統一する
- シンジケーションに注意する
- 定型文の繰り返し利用を避ける
- 記事の仮置きをやめる
- 類似コンテンツを少なくする
なお、他サイトのコンテンツをコピーして利用することも重複コンテンツといいますが、これは悪質な行為としてペナルティを受けることがありますので絶対にやめましょう。
301リダイレクトを利用する
似ているページや同じ内容が多く含まれるページがある場合には検索エンジンの評価が分散してしまう可能性があるため、重複ページは削除し301リダイレクトを使って最も評価すべきページに評価を集約すべきです。
301リダイレクトの期間は長くても問題ありませんが、おおよそ1年あればリダイレクトは解除しても構いません。
内部リンクの形式を統一する
正規化に似ているのですが、内部リンクを貼る際のURLの形式は統一すべきです。
例えば、以下の3つは同じURLですが評価を分散させないためには1つにまとめた方がよいでしょう。
- https://example.com/sample/
- https://example.com/sample
- https://example.com/sample/index.html
シンジケーションに注意する
シンジケーションには複数の意味がありますが、WEB上のシンジケーションとは第3者のサイトに記事提供(記事配信)のことを指します。
シンジケーションは両者の同意があるとはいえ完全に同じ記事を配信するという点ではコピーコンテンツです。つまり、どちらか片方しか検索エンジンに出てこないという可能性があります。オリジナルが評価されれば問題ありませんが、コピーの方が評価されることもあり、たびたび議題に挙がります。
対応策としてはコピー記事は元記事のURLをcanonicalする方法がありますが、ほとんどの場合でこの手法は取られません。代替案としてはコピー記事から元記事に対してリンクを貼ったり、コピー記事ではnoindexするなどの方法があります。
余談ですが、2018年にコンテンツシンジケーションで元記事にcanonicalをしたということでR25というメディアが英断を下したと話題になったことがあります。シンジケーションでcanonicalをするということはそれほど珍しいことです。
定型文の繰り返し利用を避ける
サイトでよく使われる定型文が長い場合には改善の余地があります。定型文が使われることはよくありますが、頻出するということであれば要約のみを載せて詳細は別ページに掲載したほうが記事同士の重複がなくなります。
定型文でなくても内容が非常に似通ったものがたびたび出てくるという場合には書き方を修正することで重複がなくなることがあります。
記事の仮公開をやめる
完成していない記事の仮公開(スタブ、プレースホルダ)は避けるべきです。完成していない記事は公開すべきではなく、ユーザーにとっても有用ではありません。検索エンジンがクロールした際に低品質なコンテンツと評価されてしまう可能性もあります。
ただし、追記が前提の記事や一旦完成品として公開したものを追記することに問題はありません。
類似コンテンツを少なくする
メディアを長く運用していると内容が似ているものが出てくるということはよくあります。しかし、内容が似ているものは重複コンテンツとして判断されたり、評価が分散されたりするリスクがあり望ましいものではありません。
可能な限り統合し301リダイレクトをすることでSEO評価を高めることができます。
リンクをクローラーに合わせる
Googleのクローラーはサイト内のリンクを辿ることができますが、辿ることができるのはアンカータグ<A>だけです。アンカータグ以外のリンクは原則的に辿ることができませんので極力避けるべきです。
正しいリンクの例
- <a href=”https://example.com” >
上記のようにアンカータグを用い、hrefを使ったリンク(通常のリンク)がクローラーが辿れるリンクです。これ以外のものは評価されませんのでご注意ください。
誤ったリンクの例
- <a onclick=”goto(‘https://example.com’)”>
- <input type=”button” onclick=”location.href=’https://example.com’ “value=”sample”>
- <button type=”button” onclick=”location.href=’https://example.com'”>
上記のような例は画面遷移はできるもののクローラーが辿れないリンク形式です。1つ目はアンカータグを使っていますがjavascriptのonclickを利用しているため避けるべきです。2つ目、3つ目はアンカータグを使っていないリンク形式ですのでクローラーにリンクを辿ってもらうことはできません。
※クローラーに辿ってもらうという点で誤った例として紹介していますが、動作が想定した通りであれば上記の例であっても問題ありません。
Googlebot をブロックしない
Googlebotはrobots.txtを利用することでブロックすることができます。しかし、小規模サイトではrobots.txtを設定する必要がないこともよくありますし、大規模サイトでもそれほど頻繁に設定変更するものではありません。
さまざまな理由でrobots.txtを設定することはありますが、設定が誤っていた場合にはインデックスが進まなくなったり、現在のサイトの順位が下がったりする恐れがあります。
検索エンジンに評価してもらうべきページはブロックしてはいけませんので、設定には細心の注意を払って行ってください。
WEBサイトをテストする方法
サイト運営をしていく上でA/Bテストを行うことはよくあります。ボタンやキャッチの位置や色を変えるだけでCVRが大きく向上することもあるため、サイトによっては頻繁に行われます。
しかし、テスト期間中はサイトを変更することになるので検索結果に影響が出ることがあります。影響があまり出ないようにするためには以下のようなことにご注意ください。
- テストでもクローキングは行わない
- canonicalを使う
- 302 リダイレクトを使う
- テストは必要な期間だけ行う
※ここでは検索エンジンに影響が少ない方法として上記4つを紹介していますが、Googleオプティマイズなどのツールを使うことでも解決できます。
テストでもクローキングは行わない
クローキングとはユーザーとGooglebotに異なるURLを設定することです。クローキングはガイドラインに違反する行為であり、A/Bテストのような試験であっても許容されません。
検索順位が下がったり、検索結果から消えたりすることがありますので絶対にやめましょう。
canonicalを使う
A/Bテストでは非常に似ている別ページを作成し、どちらが優れているのかを検証するテストです。そのため、元ページとテストページが重複コンテンツとして判断されるリスクがあります。
このリスクを避けるため、テストページには元ページに対してcanonicalを行い、クローラーにどちらを評価すべきを指定しておく必要があります。
ここで注意点ですが、テストページであってもnoindexではなくcanonicalを行ってください。テストページが元ページの別パターンであることを検索エンジンに伝える必要がある多ためです。
302 リダイレクトを使う
A/Bテストで元URLから別パターンのURLにリダイレクトをかける際に301リダイレクトではなく、302リダイレクトを使うようにしてください。
301リダイレクトは恒久リダイレクトですので、一度転送設定をした後に設定を戻することはないということを意味します。302リダイレクトは一時的リダイレクトですので転送をかけても元に戻すことが前提です。
302リダイレクトを使っていればテスト終了後にリダイレクトを外すだけで元に戻ります。
テストは必要な期間だけ行う
Googleは必要以上に長い期間テストを行っているサイトを見つけた場合、ユーザーを騙す意図があるものと判断することがあります。どの程度の期間が長いと判断されるかはGoogleも公開していませんが、目的に合ったデータがたまったら早い段階でテストデータは削除し、元に戻すべきです。
まとめ
URLをシンプルにする理由、複雑なURLになる理由、回避策、重複コンテンツなどのSEO対策ガイドラインを説明してきましたが、すべてはGoogleにクロールさせることに繋がります。
SEOでは「クロールしてもらう」、「インデックスしてもらう」、「ランキングしてもらう」の3つが必須です。今回は特に「クロールしてもらう」に注力いたしました。コンテンツを作れば検索順位が上がるというのも事実ですが、その前のテクニカルな部分を対策しないと損をする可能性があります。