BtoBのテクニカルSEOで最低限やること｜全部やらずに効く範囲だけ確認する

テクニカルSEOを全部やる必要がない理由

世に出回っている施策リストは、数万ページのメディアやECサイトまで含めて書かれています。BtoBサイトの規模では、そのうち半分以上は最初から関係がありません。

施策リストが長いのは、あらゆる規模を想定しているから

テクニカルSEOの解説記事が扱う施策の多くは、ページ数が膨大なサイトで起きる問題への対処です。クローラーが全ページを回りきれない、パラメータ付きURLが無限に生成される、ページネーションの処理を誤って商品ページが重複する。こうした事象は、数万ページのECサイトや大規模メディアでは実際に起きます。

一方、BtoB企業のサイトはサービスページ、事例、会社情報、記事を合わせても数十から数百ページの規模です。クロールが追いつかない状況はまず起きず、robots.txtでクロールを制御する必要も、パラメータの正規化ルールを設計する必要もありません。それでも施策リストにはそれらが並ぶので、読んだ側は「やっていないこと」が10個あるように錯覚します。

効かないことをやっても、商談は増えない

テクニカルSEOでできることは、突き詰めれば「検索エンジンが自社のページを正しく取得して、内容を理解できる状態にする」ことだけです。すでにその状態にあるなら、さらに技術的な手を入れても読まれる回数は増えません。

やること・やらないことの一覧

この記事で扱う範囲を先に示します。優先度は、BtoB企業が自社で運用している数百ページ規模のサイトを前提としています。

最初に確認するのは、インデックスされているかどうかだけ

公開した記事が検索エンジンに登録されているか。テクニカルSEOで唯一、毎回確認する価値があるのはこれだけです。

URL検査に貼るだけで終わる

やり方は単純です。Search Consoleを開き、画面上部の検索窓に記事のURLをそのまま貼り付けます。数秒待つと「URLはGoogleに登録されています」か「URLがGoogleに登録されていません」のどちらかが表示されます。前者なら技術面の確認はそこで終わりです。1本あたり10秒程度なので、公開時と公開2週間後の2回やれば十分です。判断すべきなのは「2週間経っても登録されていない記事があるか」だけです。

ページレポートで全体の登録状況をつかむ

Search Consoleの左メニューにある「ページ」を開くと、登録されているページ数と、登録されていないページ数、そして登録されていない理由の内訳が出ます。ここで見るべきは、登録されていないページの理由の上位に何が並んでいるかです。

「見つかりませんでした（404）」や「リダイレクトあり」は、すでに消したページや移動済みのページなので放置して構いません。注意が必要なのは、読まれたいはずの記事が「クロール済み – インデックス未登録」や「検出 – インデックス未登録」に入っている場合です。

インデックスされないときの切り分け手順

原因はほぼ5つのどれかです。上から順に見ていけば、制作会社に相談すべきかどうかも同時に判断できます。

Search Consoleの表示から原因を読む

URL検査の結果画面には、登録されていない理由が短い文言で表示されます。この文言がそのまま原因の手がかりになります。主なものを整理します。

自分で直せるもの、制作会社に頼むもの

この5つのうち、マーケ担当が自分で対応できるのは3つです。noindexはCMSの投稿画面から外せることが多く、内部リンクは関連する既存記事から1本張れば済みます。内容の重複は編集判断なので、これも自分の領域です。

制作会社に依頼が必要なのはrobots.txtとcanonicalです。どちらもサーバー上のファイルやテーマのテンプレートを触る話で、間違えるとサイト全体が検索結果から消えます。依頼するときは「このURLがrobots.txtでブロックされているとSearch Consoleに出ているので、該当行を確認してほしい」と、Search Consoleの表示文言をそのまま伝えるのが最も早く伝わります。

公開から2週間で判断する

登録までの時間はサイトの状態によって差がありますが、更新が続いているサイトなら、公開から2週間経っても登録されないのは何かが起きているサインです。逆に、公開翌日に登録されていないことを問題視するのは早すぎます。

運用としては、月に一度まとめて2週間以上前の記事をURL検査にかけるのが現実的です。10本あっても2分で終わります。この確認を習慣にしておけば、「半年書き続けたのに、そもそも登録されていなかった」という最悪の事態は防げます。

URL設計とパンくずは、ページを増やす前に決める

URLは後から変えるとコストが跳ね上がります。だからこそ、最初に決めて、その後は触らないのが正解です。

決めるのは3つだけ

URL設計と言われると難しく聞こえますが、日々の運用で必要な判断は3つに絞れます。1つ目は階層の深さです。トップから2階層、深くても3階層に収める。記事なら「ドメイン/academy/記事スラッグ/」の2階層で十分で、カテゴリを階層に含める必要はありません。含めると、分類を変えたときにURLまで変わってしまいます。

2つ目はスラッグです。英小文字とハイフンかアンダースコアで、内容が推測できる短い英単語にする。日本語をURLに入れると、共有時にエンコードされた長い文字列になり、営業がメールに貼ったときに見栄えが悪くなります。3つ目は日付を入れないことです。「/2026/09/」のような構造は、記事を更新しても古い日付が残ります。

パンくずは、ユーザーのためのものだと考える

パンくずリストは、検索エンジンにサイト構造を伝える役割があると説明されることが多いのですが、BtoBサイトで本当に効くのは読者側の効果です。検索から記事に直接着地した人が、「この会社は何をやっている会社なのか」を確認する動線がパンくずです。ここからサービスページに移動する読者は一定数います。

実装は、テーマにパンくずの機能があれば有効にするだけで、多くの場合は構造化データも一緒に出力されます。自前で作る必要はなく、依頼するなら「パンくずを全ページに出してほしい」の一言で伝わります。

すでに公開しているURLは、原則として変えない

設計を見直した結果、既存のURLが理想と違っていると気づくことがあります。それでも、動いているURLを変えるのは勧めません。リダイレクトの設定漏れ、外部リンクの切断、営業資料に載っているURLの無効化と、失うもののほうが大きいためです。変えるとすれば、サイト全体を作り直すタイミングに限ります。その場合のURL移行と301リダイレクトの設計は、リニューアル案件固有の論点としてBtoBサイトリニューアルの進め方で扱っています。日々の運用でURLを触る判断は、基本的に不要だと考えてください。

タイトルとメタディスクリプションは、クリックの問題として扱う

この2つは技術の話ではなく、検索結果という一覧の中で選ばれるかどうかの話です。だから毎回書く価値があります。

タイトルは書き換えられることがある前提で書く

設定したタイトルタグが、検索結果ではそのまま表示されないことがあります。検索エンジンが、そのページの見出しや本文から別の文言を組み立てて表示するためです。これは不具合ではなく通常の挙動なので、書き換えられたこと自体を問題視する必要はありません。

ただし書き換えが起きやすいのは、タイトルが長すぎる場合、キーワードを詰め込みすぎている場合、中身とタイトルがずれている場合です。30文字前後で、内容を正確に表し、余分な装飾がないタイトルなら頻度は下がります。文字数を守ることより、中身との一致を優先してください。

メタディスクリプションは順位を動かさない

メタディスクリプションは検索順位の要因ではありません。ここに狙いのキーワードを何度入れても、順位には影響しない前提で扱うのが正しい理解です。それでも書く理由は、検索結果に表示される説明文の候補になり、クリックするかどうかの判断材料になるからです。

BtoBの検索結果には似たタイトルの記事が並びます。その中で選ばれるには、「誰向けか」と「どこまで具体的に書いてあるか」が説明文から伝わる必要があります。読者の状況を1文目に置き、扱う範囲を2文目以降に並べる形が扱いやすいでしょう。

重複しているタイトルがないかを確かめる

記事が増えてくると、似たタイトルのページが自然に生まれます。「BtoBマーケティングの始め方」と「BtoBマーケティングを始めるには」のような組み合わせです。この状態は、どちらのページを検索結果に出すかの判断が安定せず、両方とも中途半端な位置に留まる原因になります。

確認は、Search Consoleのパフォーマンスレポートで同じ検索クエリに対して複数のページが表示されていないかを見るのが確実です。該当するペアが見つかったら、片方の切り口を変えるか、統合するかを決める。これはテクニカルSEOではなく編集の仕事ですが、技術的な確認から発見できる問題です。どちらを残すかの判断に迷う場合の相談も受け付けています。

構造化データはどこまでやるか

入れておく価値はありますが、入れたことで検索結果の見た目が変わると期待しないでください。判断軸は機械可読性です。

検索結果の見た目は、もう変わらない前提で考える

構造化データの解説では、「検索結果にQ&Aが展開されて目立つようになる」という説明がよく使われます。しかしFAQの構造化データによる検索結果上の表示は、2023年に大半のサイトで対象外になりました。現在は、一部の限られたサイトを除いて、FAQを実装しても検索結果の見た目は変わりません。

この仕様は今後も変わる可能性があります。だからこそ、「見た目が変わるから入れる」という理由づけで社内を説得するのは避けたほうがいい。仕様変更のたびに施策の根拠が崩れるためです。入れる理由は別のところに置きます。

入れる理由は、内容を機械が読める形にしておくこと

構造化データの本質は、ページの内容を人間向けの文章とは別に、機械が解釈できる形で明示することです。この記事はいつ書かれた誰の記事なのか、この質問文に対応する回答文はどれか、このページはサイトのどの階層にあるのか。これらをHTMLの見た目に依存せず、決まった形式で書いておく。

この価値が高まっているのは、検索エンジン以外のクローラーが増えているためです。AIの回答エンジンが情報源としてページを読むとき、質問と回答の対応関係が明示されているページと、見出しと段落だけで構成されたページでは、読み取りの確実性が変わります。順位が上がるかどうかとは別の軸で、内容を正確に伝えるための実装だと考えてください。AI検索側の動きについてはChatGPT検索がBtoBマーケティングに与える影響とBtoBのLLMO対策のやり方で扱っています。

実装は記事ごとではなくテーマ側で一度だけ

構造化データを「記事を書くたびにJSON-LDを手で書く作業」だと捉えると、続きません。書き忘れが出ますし、書式を間違えたときに全記事を直すことになります。実装はテーマ側に寄せて、記事側は普通に書くだけという形にするのが現実的です。

Ampelがこのメディアで採っているのも同じ形です。記事側はFAQをdl・dt・ddの素直なHTMLで書くだけにして、テーマ側で一度だけ、ページに出力されるWebPageのノードにFAQの情報を繋ぐ実装を入れました。記事のHTMLには一切手を入れていません。これにより、過去に公開した記事にも、これから書く記事にも、同じ形式が自動で適用されます。制作会社に依頼する場合も、「記事ごとではなくテーマ側で一括して出力してほしい」と伝えれば意図は通ります。

入れるなら、この3つで足りる

BtoBのオウンドメディアで実装する価値があるのは、記事であることを示すもの、パンくずの階層を示すもの、そして運営組織を示すものの3つです。加えてFAQを載せている記事があれば、そこに対応する実装を足す。これ以上の種類を追加しても、BtoBサイトで使いどころはほとんどありません。

表示速度はどこまで気にするか

数値目標を追いかけるのはやめて構いません。ただし「明らかに遅い」状態だけは、順位以前に読者が離脱するため放置できません。

Core Web Vitalsは、やらない判断でいい

Core Web Vitalsは、表示の速さや画面の安定性を数値化した指標群です。基準値が公開されているため、これを満たしにいく改善案が制作会社から提案されることがあります。ただ、BtoBサイトでこの数値を基準内に収める作業に工数を割いても、商談数への影響はまず見えません。

理由は2つあります。この指標が順位に与える影響は内容の一致度に比べて小さいこと。そして、BtoBの検索は業務時間中のPCと安定した回線で行われることが多く、多少の遅さが離脱に直結しにくいことです。数値を緑にすること自体を目的にした改善は、優先順位を下げて構いません。

明らかに遅い場合だけ、原因を特定して1点だけ直す

開いてから内容が見えるまでに数秒かかるサイトは別です。判断は数値ではなく、自分のスマートフォンで記事を開いて「遅い」と感じるかどうかで構いません。この規模の遅さの原因は、たいてい限られています。圧縮していない大きな画像、トップページに置かれた自動再生のスライダーや動画、多すぎる外部スクリプト、読み込みの重いフォント。制作会社に相談するときは「全体的に速くしてほしい」ではなく、「記事ページの表示が遅いので、画像の圧縮と不要なスクリプトの削除から見てほしい」と範囲を指定したほうが、費用も工数も抑えられます。

重複コンテンツは、社外のコピーより自社の作り方で起きる

他社に文章を盗まれる心配より、自社が意図せず同じ内容のページを複数持ってしまうほうが、はるかに高い頻度で起きます。

よくある発生源

典型的なパターンは3つです。事例ページを業種別・課題別の両方から作り、同じ事例が2つのURLで存在する状態。タグやカテゴリのアーカイブが、記事の抜粋だけを並べた似たページを大量に生む状態。そして、wwwありとなし、httpとhttps、末尾スラッシュの有無で同じページに複数のURLでアクセスできる状態です。

3つ目は確認が簡単です。ブラウザで自社サイトのトップページをwwwなしで開き、URLが自動的にwwwありへ書き換わるなら問題ありません。書き換わらずそのまま表示されるなら、リダイレクトの設定を依頼してください。

canonicalとnoindexの使い分け

重複への対処は2つの方法があります。同じ内容が複数URLにあり、そのうち1つを正規のページとして扱いたい場合はcanonicalを使います。事例ページの重複はこちらです。一方、そのページ自体を検索結果に出す必要がない場合はnoindexを使います。タグアーカイブや、サイト内検索の結果ページがこれにあたります。

そもそも作り方の段階で防ぐ

技術的な対処より効くのは、ページを作る前のルールです。事例は1件につき1ページとし、業種別・課題別の切り口は一覧ページ側でフィルタとして持たせる。記事の切り口が既存記事と重なりそうなら、書く前に統合を検討する。この2つを決めておけば、重複の大半は発生しません。事例ページの作り方はBtoB導入事例の作り方で扱っています。

Search Consoleで最初に見る3つの画面

機能は多いのですが、日常的に開く必要があるのは3つだけです。それ以外は必要になったときに探せば足ります。

検索結果のパフォーマンス

最初に開くのはここです。左メニューの「検索結果」を選び、上部の「平均掲載順位」と「平均CTR」にもチェックを入れます。そのうえで下部のタブを「クエリ」にすると、どんな言葉で自社サイトが表示され、クリックされているかが一覧で出ます。

見るべきなのは、表示回数は多いのにクリック率が低いクエリです。検索結果には出ているが選ばれていない状態なので、タイトルとメタディスクリプションの書き換えで改善できる余地があります。逆に、クリックはされているが商談につながっていないページがあるなら、それは技術でもタイトルでもなく、ページ内の導線の問題です。BtoBの問い合わせフォーム改善のほうを先に見てください。

ページ（インデックス作成）

2つ目は前述のページレポートです。月に一度、登録されていないページの理由を眺めて、意図しないものが増えていないかを確認します。数字が多少上下することは正常なので、内訳の中身だけ見れば十分です。

URL検査

3つ目は画面上部の検索窓です。個別のページについて確認したいときに使います。記事を公開した直後にここから「インデックス登録をリクエスト」しておくと、登録までの時間が短くなることがあります。ただしリクエストしたからといって必ず登録されるわけではないので、過度に依存しないでください。

見なくていい画面

それ以外のレポート、たとえばウェブに関する主な指標や、リンクレポート、セキュリティの問題などは、Search Consoleから通知が来たときに開けば足ります。定期的に眺めても、そこから打つべき手が出てくることはほとんどありません。何を見るかを絞ること自体が、限られた時間で運用を続けるための設計です。数字の見方全般はBtoBマーケの効果測定で扱っています。

自分で確認する範囲と、制作会社に依頼する範囲

技術的なことをすべて理解する必要はありません。何が起きているかを正確に伝えられれば、実装は任せられます。

マーケ担当が持つべきなのは、判断と発見

ここまで扱った項目のうち、マーケ担当が自分でやるのは、インデックスの確認、原因の切り分け、タイトルとメタディスクリプションの作成、そして重複の予防です。いずれもコードを書く作業ではなく、状態を確認して判断する作業です。これは外注しにくい部分でもあります。どのページを残したいか、どの記事とどの記事が重なっているかは、事業を理解していないと判断できません。

依頼するときの伝え方

制作会社への依頼で最も伝わりやすいのは、Search Consoleの表示文言と対象URLをそのまま渡す形です。「SEO的に良くないらしいので直してほしい」という依頼は、相手が何をすればよいか判断できず、見積もりも膨らみます。「このURLについて、Search Consoleに『robots.txtによりブロックされました』と出ています。該当する記述を確認して、この記事がクロールされる状態にしてください」まで書けば、作業範囲が確定します。

構造化データも同様に、「記事ページとパンくずの構造化データを、記事ごとではなくテーマ側で一括して出力する形で実装してほしい」と伝えます。実装方法まで指定する必要はありませんが、記事単位の作業が発生しない形にしたい意図は伝えるべきです。

どこまで自社で持つかを決めておく

依頼の境界が曖昧なままだと、月次の保守費に含まれるのか都度見積もりなのかが毎回議論になります。「Search Consoleでエラーが出たときの調査と修正は保守に含む」「新機能の実装は都度見積もり」といった線を最初に引いておくと、確認を先送りにする理由がなくなります。保守範囲の線引きについての相談も受け付けています。

なお、コンテンツを増やす体制そのものが安定していない段階で技術面の整備を先にやると、順番を間違えます。運用のペース設計はBtoBオウンドメディアの運用体制に、キーワードから運用までの全体設計はBtoB SEOコンテンツ戦略の設計手順にまとめています。

まとめ

BtoBサイトのテクニカルSEOで、日々の運用として必要なのは多くありません。公開した記事がインデックスされているかを確認すること。されていない記事があれば、5つの観点で原因を切り分けること。タイトルとメタディスクリプションを毎回書くこと。この3つを習慣にすれば、技術が原因で成果が出ないという状況はほぼ避けられます。

一度決めて終わりにするのが、URL設計とパンくず、そして構造化データです。いずれも制作会社に依頼する領域で、記事ごとの作業が発生しない形にしておくのが要点になります。構造化データについては、検索結果の見た目が変わることを期待せず、内容を機械が読める形にしておくという理由で判断してください。

そして、Core Web Vitalsの数値改善とクロールバジェットの最適化は、この規模ではやらない判断で構いません。技術面に時間を使うほど成果が伸びるわけではなく、問題がないことを確認したら中身に戻る。テクニカルSEOに対する態度としては、これが最も費用対効果が高いと考えています。

よくある質問

テクニカルSEOはコンテンツSEOより先にやるべきですか

先にやるべきなのは、インデックスされているかの確認だけです。ここに問題がなければ、残りのテクニカル施策は後回しにして中身の改善に進んでください。順序を逆にして技術面の整備に数か月かけると、その間ページが増えず、検証できることも増えません。ただし、記事を公開しても登録されない状態が続いているなら、それは中身以前の問題なので最優先で切り分けます。

構造化データを入れると検索順位は上がりますか

構造化データそのものが順位を押し上げるとは考えないほうが安全です。役割は、ページの内容を機械が解釈できる形で明示することにあります。FAQの構造化データによる検索結果上の表示は2023年に大半のサイトで対象外になっており、見た目の変化を期待して入れる施策ではなくなりました。判断するなら、AIの回答エンジンを含むクローラーが内容を正確に読み取れる状態にしておく、という理由で入れてください。

Core Web Vitalsの数値が基準を下回っていますが、対応すべきですか

数値そのものを基準にするなら、対応は優先度を下げて構いません。BtoBサイトの規模では、この数値を改善しても商談数への影響はまず見えないためです。判断は自分のスマートフォンで記事を開き、内容が見えるまで待たされると感じるかどうかで行ってください。明らかに遅い場合は、画像の圧縮と不要なスクリプトの削除という範囲を指定して制作会社に依頼するのが、費用を抑えつつ効く進め方です。

記事を公開してもインデックスされません。何から確認すればよいですか

Search ConsoleのURL検査に該当URLを入れ、表示される理由の文言を確認するのが最初です。「noindexタグによって除外されました」なら投稿設定やテーマの設定、「robots.txtによりブロックされました」ならサーバー上のrobots.txt、「代替ページ」ならcanonicalの指定先を見ます。「検出 – インデックス未登録」は内部リンクがゼロのことが多く、関連記事から1本リンクを張れば解消することがあります。「クロール済み – インデックス未登録」は技術ではなく内容の問題で、既存ページとの重複を疑ってください。