【SEO】数百万ページを超えるDB型サイトのページエラーと向き合ってみた
このnoteは、IVRy 紅白Advent Calendar 2023 の紅組・7日目の記事です。
昨日の担当は takeyasuくんで「2023年、IVRyインサイドセールスの変化と来年私が目指したいこと」でした。
明日はSATOKENさんの事業開発についての記事が出ます。乞うご期待！
／
— IVRy（アイブリー）｜電話DX (@IVRy_jp) December 1, 2023
🔈今年も恒例！IVRyアドベントカレンダー実施
＼
2023年の総括に加え、今回は紅白対抗戦で各teamが1日1人ずつ発信します！
ラインナップはコメントをチェック！
ぜひお楽しみください♪ pic.twitter.com/PDphLmadtE
前日の竹安くんの記事⇩
はじめに
こんにちは。IVRyマーケチームの八木です。
最近、焼酎をティーバッグのお茶で割る「コウバシ茶割り」にハマっています。3杯目から青汁の粉を足すといつまでも飲み続けられるのが特徴で、飲めば飲むほど健康になるとかならないとか。先日、それを飲み過ぎた次の日、鼻水が緑色でした。
さて、今回はIVRyアドベントカレンダー紅組7日目ということで、私が入社してから関わっている「電話番号検索サイト」をテーマに、DB（データベース）型サイトのSEO、それもGoogleサーチコンソールのページエラーとどう向き合ってきたかを振り返ります。
DB型サイトのSEOがメインテーマですが、サーチコンソールのエラー対応は小型サイトであっても重要です。サーチコンソール上でページエラーが大量発生したときに「どこから手をつければいいの？」と悩む孤独なSEO担当者のもとへ、この記事が届けばいいなと思います。
自己紹介
2023年5月に入社し、SEOやメールマーケを担当しています。前職でもコンテンツSEOをやっていて、キーワードマーケに携わって7年以上が経ちました。
IVRy（アイブリー）とは
月額3,000円〜で始められる電話自動応答サービスで、よくあるお問い合わせや電話の取次を自動化して電話対応の負担を軽減します。幅広い業種に導入いただいて、累計アカウントも8,000を超えました。
「電話番号検索」サイトって？
急にかかってきた電話番号、折り返す前にネット検索することがあると思います。そういうときに役立つサイトを作り、「電話といえばIVRyだよね」と言ってもらえるようなサイトとして立ち上がりました。
2023年3月にリリースしたサイトで、2023年12月1日現在でGoogleにindexされているページ数は300万超。まだまだ成長中で、課題もありますが、紆余曲折を経てindex数を増やしてきました。
社内では「telsearch（テルサーチ）」と親しみを込めて？呼ばれていたりします。
他社さんのサイトと比べると、まだまだこれからです。
DB型サイトSEOの難しいところ
一般的なHPのSEOであれば、狙いたい検索キーワードに対して、ページ単位でコンテンツ設計をし、ユーザーニーズにあわせて個別最適をしていくことが多いと思います。
一方でDB型サイトの場合、求人情報や物件情報など一定の「型」が存在しています。UGC（ユーザー生成コンテンツ）を収集してコンテンツを増強していく方法もありますが、DB型サイト運営者が取り組むのはエラーを極力減らし効果を最大化する、という施策になります。
telsearch（電話番号検索サイト）は、現状UGCを表出していない（※）上に、電話番号という理論上は9億を超える膨大なデータを扱うサイトです。個別最適は難しいのはもちろんのこと、データを持つページとそうでないページが生成されることから、序盤は多くのエラーを吐いていました。
※フォームで収集のみ実施しています。
ただ、エラーに向き合っていくことでDB型サイトSEOにおけるスタンスが明確になりました。施策として斬新なことはしておらず、基本的なエラー対応を順序立てて進めたことが結果につながっています。
長くなりますが、順を追って振り返ります。
エラーから見るtelsearchの歴史
課題①：500系エラー
序盤に頻発したエラーとしてサーバー側の問題である500系のエラーがありました。telsearchで多かったのは503エラーで、そもそもURLをリクエストしたタイミングで負荷に耐えきれずエラーページが表示されてしまうため、クローラーはコンテンツを読みたくても読めない状態です。
このエラーに関しては技術的な要素も多く、エンジニアの皆さんの知見をたくさんお借りしました。どこからリクエストが来ているかも含めてウォッチした上で、以下のような対策を実施しています。
キャッシュ表示で対応
サーバー増強（スケールアップ）
503エラーの対応としては、そもそも転送されるデータ量を減らすためにJavaScriptやHTML、画像ファイルを圧縮する方法もありますが、上記2点の対応を実施したことで503エラーは激減しています。
課題②：検出-インデックス未登録
序盤に最も多かったエラーが「検出-インデックス未登録」でした。
状態としては、クローラーがURLの存在は認識しているがクロールはしていない。中身もほぼ読んでいない、という状況と考えています。上記の503エラーも関与していると思われますが、クローラーに対して与えている印象として推測されたのは
いくつかURLをクロールし、同じようなページ群と認識されている
モバイルエラーなどがあり、クロールにあたってストレスの多いページと認識されている
つまり、読む価値がないURLと認識されている
個別にインデックスリクエストを送ることで登録がなされる場合が多く、小型サイトにおける上記エラーはリクエストで一定対応が可能です。ただし、DB型サイトの場合は全く工数に見合いません。
そこで、このエラーに対してとった対策は以下のようなものでした。
ページごとに最低限のテキストボリュームを持たせる
モバイルエラーへの対応
テキストボリュームという観点で、初期のtelsearchにおいては、電話番号・事業者名・地域名・カテゴリ名といった基本的な要素を並べたテーブルしか存在いませんでした。そこで各要素の情報について「冒頭にテキストで概要を記載する」という対策でボリュームを担保しました。
モバイルエラー対応も、個人的には非常に重要と考えています。そもそもモバイルで正しく表示されないサイトは読みませんよ、というGoogleの意思を感じています。
モバイルエラーに関してはサーチコンソール内でGoogleが丁寧に原因を提示してくれるので、これは一つずつ潰していきました。telsearchにおいては、大量のリンク群があり、リンクどうしが近くクリックがしにくいという課題があったため、デザイン調整によってこのエラーを解消しています。
課題③：noindexとrobots.txtの使い分け
膨大なページ数に対して、実際にクロールしてもらうページを限定するための制御方法として、noindexとrobots.txtの設定があります。
telsearchでもこの制御を進めていました。
一度、誤ってindexされたページに対してnoindexとrobots.txtによる否認を同時に実施してしまった際に、一向にnoindexを検知せずエラーを吐き続けていました。
robots.txtはクローラー自体が来るのを拒否してしまうので、新たなシグナルを入れても検知されなくなってしまいます。同時に実装した場合にはnoindexを検知しないまま、意図しないindexが続きました。
意図しないindexを外す：noindex
indexされていないページをクローリングさせない：robots.txt
と使い分けて、不要なエラーを吐かないようにしました。
課題④：400系エラー
telsearchでも400系のエラーは多く、通常の404エラーとソフト404の2種類がその主だったものでした。対応としては、
404はリンク先として設定されているものは修正、ページ自体は無視
ソフト404は緊急度高く対応
という方針をとりました。
404エラー自体はレスポンスとしては正しく、「存在していないものを存在していないと教えている」エラーのため、数多あるエラーの中での優先順位はかなり低いものでした。
一方で、ソフト404は見え方が「存在していないページ」にも関わらず、レスポンスとしては存在ページと同等のもの（200）を返しているページです。これは逆に優先度高く対応をしていました。
特にデータを持たないページにてソフト404のケースが見られていました。該当ページにnoindexを付与することで、減少に転じることができています。
ちなみに、ページの404エラー自体は問題ありませんが、404ページに対してのリンクが残る状態はあまり美しくないので、ツールを使って404ページへのリンクを検知するなどもしています。
課題⑤：クロール済み-インデックス未登録
一定、上記のようなエラーを解消してクローラーが回ってくるようになると、具体的なページコンテンツが評価されていきます。コンテンツ自体の評価が足りないと、本エラーが散見されることになります。
一定、序盤の対策でテキストボリュームを増加する対策はしていたものの、ページ間のコンテンツの一致率が高かったと推測しています。つまり、クローラーからすると、ページごとにユニークな箇所が少なく、似たようなページ群として認識されていた可能性があります。
そこで、ここに対しては以下のような対策をとっています。
表出できる項目を増やす
地域情報や予測される回線情報など補足できる情報を足す
telsearchの詳細ページを見ると、現在は下記のようになっています。
表内の項目を増やしています。
無闇にコンテンツを足しても、低品質なコンテンツとして認識されるリスクがあります。あくまで電話番号の情報を知りたい人に対して、一助になるような情報を追加しています。
ページ単位の個別最適が難しい中で、PdMのmiyazakiくんが都道府県・市区町村情報をかなり網羅的に調査し、ボリュームアップを推進してくれました。
結果、一定量のコンテンツが提供できる型ができてくると、エラーは減少に転じました。その後も完全に解消とまでは至っていませんが、リクエストをすればほぼ確実にindexされるという状況に改善されています。
課題⑥：index数増加のためクローラーへのストレスを減らす
上記までのエラーの対応で、数十万件ほどのindexは実現できていました。ただ、コンテンツが存在しているページのボリュームを考えるとまだまだ少なくて、どうしたらスケールするだろう？と頭を悩ませていました。
ここでSEOチームの若きエース・TERUくんが起案してくれたのが、各ページへの構造化データの実装でした。構造化データの実装はやらないよりやった方がいい、程度に考えていたのですが、この施策をきっかけにindexが爆増します。
10月上旬に各電話番号ページに対して構造化データを実装、修正を経て10月中旬からindexが急激に増加しはじめました。
構造化データとして追加した項目としては、各ページ内に掲載をしている事業者情報や電話番号など。DB型サイトの情報の持たせ方と構造化データの相性が非常に良く、クローラーがコンテンツを読み解くストレスが軽減されたのでは？と見ています。
DB型サイトSEOと向き合って見えたこと
エラーと向き合った上で以下のスタンスが明確になりました。
エラーの本質を理解して段階的に対処する
コンテンツは検索ユーザーのニーズに合わせる
クローラーに負荷を与えない設計を
ここで振り返ってきたエラー対応は基本的なことばかりです。各章にて参照記事を掲載しましたが、各施策については先人の記事が大変有益ですし参考になります。telsearchの運用を経てスタンスが明確にできたのは、これらのエラーを点ではなく、線で捉え、順序立てて対応できたからだと思います。
各エラーに対しては「なぜそのエラーが出たのか？」「何から対応するべきなのか？」を理解して対処する必要があります。そもそもサーバー側に問題があるのに、無闇にコンテンツを増やしても読んでもらえません。エラーに対して個別で考えず、サイトのどこに問題があるかを俯瞰しましょう。
コンテンツを充実させる際には、検索ユーザーに沿った設計をする必要がありますが、当然ながらクローラーの存在も無視することはできません。クローラーに負荷を与えないという観点では、以下を重視しました。
・不要なページをクロールさせない
・リンクをたどって各ページを認識できる
・クローラーがコンテンツを理解させやすくする
エラー対応を通じてクローラーともどう向き合うかがはっきりしました。
この観点を共通認識として持てていると、施策も立案しやすいはずです。
個人的所感
このブログを機に、telsearchの施策を振り返ってみたわけですが、ここには書ききれないほどの紆余曲折がありました笑。それでもこれだけの結果が出たのは、PdMのmiyazakiくんが開発チームとマーケチームの間に入ってProjectを推進してくれたおかげだと思っています。
私自身、大規模サイトの運用経験はない上、技術的な知見も弱かったので、開発の方と一緒に取り組めるProjectとしてかなり勉強させてもらいました。DB型サイトSEOだけでなく、記事SEOにおいても還元できそうです。
まだまだ課題は多く、index数としても伸びしろが大きいサイトです。みなさんに「telsearchでよく番号調べるよ」「電話といえばIVRyだよね」と言ってもらえるように、telsearchも引き続き成長させていきます。
積極採用の紹介
IVRyでは各ポジション積極採用中です！
マーケチームも、SEM含め各種マーケ施策を推進してくださる方を大募集中です！SEO、リスティング広告などまだまだ白地が多く、いろんな知見を集めて事業を伸ばしていくフェーズです。
気になる方は、ぜひカジュアル面談にご応募ください。どんな人たちがいるの？など雰囲気を知りたい、だけでも構いません。
何卒よろしくお願いします。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？