この記事は、Ateam LifeDesign Advent Calendar 2022（カレンダー3）の何記事目か、です。
これは何か
検索評価を受けやすいサイト構造を作る（＝テクニカルSEOをする）ために、メディアディレクターとWebエンジニア間での素早いコミュニケーションを確立します…多分 (๑•̀ㅂ•́)و✧
主に、Google Search Console上でアラートされる「カバレッジエラー」を減衰させることができ、それによるサイト全体の検索評価の向上を促せると思います。
※対処のケースは、各サイトの規模／用いられているアーキテクチャ／そのほかのSEOの変数…などによって千差万別です。
本シートはあくまで早見表であることに留意し、各現場での議論を以って最善の対処方法を決めてもらえればと思います
なぜこれをQiitaに書くのか
本分野に取り組むにあたって、メディアディレクター（≒SEO担当者）はエンジニアリングの素養が低く、エンジニアはSEOへの理解度が低い。
おしなべて、お互いがお互いの領域について知識が薄い現場が多いよね、と感じることが多いためです。
それにも関わらず、テクニカルSEOは両者の知識と技術を必要とします。
ディレクターはSEOを考える必要があり、エンジニアは実装ロジックや工数について考慮しなければならない。
あえてエンジニアの方々が多いQiitaで書こうと思ったのはそれが大きな理由です。
この両職種間のコミュニケーションを、同一見解を持つことで少しでも建設的にしたい、と思ってます。
あと今回書くような、包括的な対策内容を載せているWebドキュメントが全然ない！なんでなん！？
ホント困るわ～ と思いながらキャリアを積んできたので、そのカウンターアタックでもあります。
では、チートシート置いておきます
シートの見方
対象となるURLに対して、左の項目①～⑥までの条件分岐を考えていき、右の「インデキシングへの対処」と「クローリングへの対処」を採択します。
まずは、左側の各条件の説明をしてきます。
①既index
対象URLが既にGoogle検索にインデックスされているか否かです。
インデックスの有無は、Search Consoleからの「URL検査」や「site:（サイトコロン）検索」によって確かめます。
②Google評価
①でインデックスが確認された場合に、対象URLへGoogle検索の評価があるかどうかです。
基本的には、オーガニックトラフィックの大小や、検索クエリでのランクイン状況などを複合的に加味して判断します。
少し難しい観点です。
個人的には、数か月単位でトラッキングしていても数～数十UUしか発生していないとか、ランクインしていても検索ボリュームが限りなく小さいクエリしかない、みたいなURLは「なし」でいいと思います。
ウェブディレクターがSEO観点から、どこまでを「あり」「なし」にするのかというしきい値を判断する必要があります。
③親URL
対象URLの親となるURLがあるかないかです。たとえば、以下のようなケースです。
親URL ： https://example.com/aaa/
対象URL： https://example.com/aaa/?plm=123
上記の場合、対象URLは親URLの出力内容を踏襲しつつ、変数で内容を絞り込んでいたり、差し替えていたりします。
この例に限らず、最終的に検索評価を集中させたい別のURLがある場合は、それが親URLであると考えてもらえれば結構です。
④類似URL
対象URLと類似した内容を出力している別のURLがあるかないか、です。こちらも前段同様に例で見ていきます。
親URL ： https://example.com/aaa/
対象URL： https://example.com/aaa/?plm=123
類似URL： https://example.com/aaa/?plm=123&var=456
肌感ですが、対象URLの出力内容と80%以上が共通してしまっているのであれば、類似URLと判断しても問題ないと思います。
仮に、親URLは無いが類似URLがあるという場合、対象URLに検索評価を集中させたいのであれば、対象URL自身が親URLとなります。
⑤テーマ性
対象URLに出力されている内容が、サイト全体が取り扱うトピックのテーマ性と沿うのか否か、という観点です。
極端な例を出すと、法律関連のメディアの中にサラダのレシピについて書かれた記事があれば、それはサイト全体のテーマ性に沿わないと言えます。
※いやいや、そんなサイトは無いだろうと僕も思いますが。
これも、ウェブディレクターが根拠を持って「沿う」「沿わない」を判断する必要があります。
一見するとジャンルが違う内容も、広義ではテーマに親和性があるというケースも考えられるためです。
個人的に、「AからBはどう考えても連想ができない」場合はテーマ性が離れすぎている、という定性的な判断をすることが多いです。
⑥ユーザー閲覧
そのURLの内容をユーザーが閲覧できる必要があるかどうかです。
転送処理や404を返すと判断しても良いか、と言い換えることができます。
その場合、対象URLに出力されていた内容はユーザーから見えなくなってしまうからです。
次に、右側の対象方法の説明です。
インデキシングへの対処
各URLについて、対Google検索で設定するべき／処置すべき内容です。
これら対処を以って、各URLの検索評価を最適化していきます。以下、対処内容の補足です。
canonicalで正規化する
検索評価させたいAというURLと、Aとほぼ同じ内容が出力されているBというURLを考えた際に、Bの検索評価をAへ正規化させる専用のタグがあります。内容重複を起こしているURLがある場合などに用いられます。
詳細な説明は以下を参照してください。
301リダイレクトさせる
前段同様、Bの検索評価をAへ移行させたい場合に301リダイレクトが用いられます。canonicalと異なり、リダイレクトによってBに出力されていた内容は見れなくなります。
古くなったURLを閉じる際や、サイトのドメイン移管などでも用いられますね。
詳細な説明は以下。
なお、JavaScriptやCryptoを用いたリダイレクトは、Google検索が非推奨としています。リダイレクトさせれば何でも良いわけではないので要注意です。
別ドメイン（もしくはサブドメイン）へ移管する
Googleはドメイン単位でも検索評価を処理します。
そのため、もし自サイトのSEOを考えた際に、不適切だと判断されるコンテンツがある場合は、別サイトに切り分けるという意味合いでドメインの変更処置を考えます。
先ほども挙げた例ですが、法律関連のメディアの中にサラダのレシピについて書かれたURLがあったとしましょう。
サイト全体の検索評価を考えれば、テーマ性を「法律」で統一すべきなので、「レシピ」のURLは排除したいです。
しかし、その「レシピ」のURLが検索評価されていたとしたら、単純に削除してしまうのはもったいない。
であれば、「レシピ」の記事は別ドメインに移管し、そこで再度、検索評価を受けていきましょうという判断します。
404ステータスコードを返す
これは読んで字のごとく、です。
対象URLに404を返せば、Googleはクローリングの減衰と、インデックスからの削除を処理していきます。
noindexする
noindexはGoogle検索のインデックスから対象URLを削除させる命令です。
こちらも、詳細はオフィシャルで確認できます。
なお、シート上ではAND、ORと表記しているように、ケースによっては複数の対処や対処の択一が必要です。
ディレクターがSEO観点、もしくはエンジニアが実装コストの観点などから、対処内容を決めていけると良いと思います。
クローリングへの対処
各URLがGooglebotにクローリングされるべきか否かについて、最適な制御を施します。
以下、対処内容の補足です。
検索評価の移行
仮に、AというURLへBというURLから検索エンジンの評価を受け継ぎたい場合、ある程度の時間を要します。
評価の移行は301リダイレクトや、canonicalを用いたURLの正規化によってなされますが、それらの処置をした後にGooglebotによるA・Bへのクローリングと、Googleのデータ処理が必須です。
そのため、主にディレクター側がSearch Consoleなどを用いて、適切に新旧URLの検索評価の移行がなされたかどうかを判断しましょうね、という話です。
クローリングを禁止する
クローリングを一切させない、ということの表現で用いています。robots.txtによるdisallow設定などが一般的です。
クローリングを防止する
サイト構造によっては、前段の「禁止」まではしづらいがクローリングさせづらい環境を作りたいというケースもあるかと思い、そのニュアンスで「防止」としています。
たとえば、対象URLに対して一切の内部リンクを設置しないといった処置をとれば、ある程度のクローリング防止はできるでしょう（※別サイトから外部リンクが飛んでしまえば、結局クローリングされてしまいますが）。
クローリングを促進する
クローリングがシュリンクしている対象URLに対して、その促進を行う処置です。
sitemap.xmlへの記載や、記載順の最適化などがあります。
クローリングを改善する
既に一定のクローリングがある対象URLに対し、さらに検索エンジンが評価しやすいための環境を用意することです。
主に、対象URLへの内部リンクを増設して行います。
最後に
チートシートという提供形式を取ったので、かいつまんだり、平易な表現で書いたりした箇所がありますので留意ください。
やはり色々な面で対策が難しい分野です。サイト規模によっては、ベストプラクティスが無いのではとも思っています。
ゆえに、ケースバイケースに対応しきれていない内容があれば、それもごめんなさいって感じです。
また、インデックスやクロール、URLの制御はミスるリスクが非常に大きいです。
必ず、ディレクターとエンジニア双方の視点で、リスクヘッジについて打ち合わせてから進めることを推奨します。
しかし、散々こういう対策をしてきた僕個人の経験則はちゃんとシートに反映できたと感じますので、冒頭でも書いた通り、あとは皆さんの現場でシナジーを生むために活用してもらえると嬉しいです。
（あと弊社のマーケティング部門のnoteも最近できたので、こっそり宣伝しておきます…）