テクニカルSEOとは？押さえる14の改善ポイント

企業が SEO に取り組み始めるとき、まず思い浮かべるのはたいてい「キーワード、記事、順位」です。

しかし、どれほど良い内容を書いても、検索エンジンがサイトのコンテンツを正しく発見し、アクセスし、解析し、インデックスできなければ、

そのコンテンツは検索結果に正しく表示されないことがあります。

これを扱うのが テクニカルSEO（Technical SEO） です。

テクニカルSEOが見るのは「記事をどう書くか」ではなく、サイトそのものが検索エンジンにとって健全な技術基盤を備えているかどうかです。

この記事では、次の内容を順に説明します。

テクニカルSEOとは何か、検索エンジンがサイトをどのようにクロール・インデックスするのか、そして robots.txt、サイトマップ、canonical、リダイレクト、JavaScript SEO、構造化データ、Core Web Vitals などの重要項目をどう理解し、どう確認すればよいか。

まずエンジニアになる必要はありません。

ただ、SEO を長期的な検索流入の源にしたいなら、少なくとも自社サイトが検索エンジンが正常に働ける技術基盤を備えているかどうかは理解しておくべきです。

テクニカルSEOとは、サイトの技術的な構造を最適化し、検索エンジンが次のことを正常に行えるようにする取り組みです。

発見（Discover）

↓

クロール（Crawl）

↓

レンダリング（Render）

↓

インデックス（Index）

↓

検索結果にコンテンツを表示する（Serve）

簡単にいえば、テクニカルSEOが扱うのは次の点です。

そのため、前に取り上げた SEO 記事の書き方とは性質が異なります。

SEO コンテンツが問うのは 「どんなコンテンツを提供すべきか？」 です。

テクニカルSEOが問うのは、むしろ 「検索エンジンがそのコンテンツを正しく処理できるか？」 です。

たとえば、企業がとても充実した SEO 記事を作ったとします。

内容そのものに問題はなくても、サイト側で次のようなことが起きている場合があります。

robots.txt が検索エンジンのクロールをブロックしている

↓

Google がコンテンツを正しく取得できない。あるいは ページに noindex が設定されている

↓

Google はクロールできても、そのページを検索インデックスに入れないよう指示されている。

あるいは 同じコンテンツが複数の異なる URL に存在している

↓

検索エンジンは、どの URL がメインのバージョンかを判断しなければなりません。

このとき canonical URL が必要になることがあります。

また、リニューアルで /old-page を /new-page に変えたとします。

旧 URL を適切なリダイレクトなしにそのまま消すと、次のようなことが起こりえます。

こうした問題はすべて、テクニカルSEOが扱う領域です。

テクニカルSEOは、SEO プラグインを入れたりサイトマップを設定したりすれば終わり、というものではありません。

通常はサイトの次のような多くの層にかかわります。

しかも、これらの項目は互いに影響し合うことがあります。

たとえば、サイトマップにある URL が載っていても、そのページ自体に noindex が設定されていれば、

互いに矛盾するシグナルになります。

あるいは、canonical が https://example.com/page を指しているのに、

その URL 自体が https://example.com/zh/page にリダイレクトしている場合、

canonical は最終的にインデックスされる正規 URL を指していないことになります。

つまり、テクニカルSEOで本当に重要なのは 「それぞれの機能に対応したかどうか」 ではありません。

サイト全体の技術シグナルが一貫しているかどうかです。

企業サイトにとって、テクニカルSEOのもっとも効率的なやり方のひとつは、コンテンツ担当者全員にテクニカルSEOを理解させることではなく、次のようにすることです。

サイトのプラットフォーム自体に、合理的な初期動作を持たせる。

たとえば、私たちのプラットフォームは現在、次のことを自動で行います。

コンテンツ担当者は、記事を作るたびにcanonical、サイトマップ、hreflang をどう設定するかを改めて理解し直す必要はありません。

こうしたルールは、サイトのシステムで一括して処理するほうが適しています。

ただし、テクニカルSEOのすべてを完全に自動化すべきだという意味ではありません。

たとえば、

といった点は、やはり SEO、コンテンツ、ビジネスの観点からの判断が必要になることがあります。

テクニカルSEOも、最終的にはサイトのコンテンツとユーザーのためにあります。

たとえば、

つまり、テクニカルSEOは 「Google にしか見えない SEO テクニック」 ではありません。

より妥当な捉え方は、次のとおりです。

企業が SEO に投資するとき、もっとも目に入りやすいのはキーワード、記事、検索順位、流入数です。

しかし、こうした取り組みには共通の前提があります。「検索エンジンがまずサイトのコンテンツを正しく取得・処理できること」です。

サイトにテクニカルSEOの問題があると、内容そのものが良くても、技術設定の誤りのせいで検索での価値を十分に発揮できないことがあります。

Google はまずページを発見しなければ、その後のクロール、インデックス、検索結果への表示にも進めません。

検索エンジンは、たとえば次のような方法で URL を発見します。

そのため、ページを公開していても、

といった状態だと、検索エンジンがコンテンツを発見・処理する効率が下がることがあります。

テクニカルSEOの仕事のひとつは、わかりやすく、検索エンジンが発見できるサイト構造をつくることです。

URL を見つけたあと、検索エンジンは実際にそのページへアクセスする必要があります。

ここでかかわってくるのが、次の項目です。

たとえば robots.txt です。

重要なコンテンツを誤ってブロックすると、検索エンジンの正常なクロールを妨げることがあります。

robots.txt はサイトのルートディレクトリにある小さなファイルにすぎないように見えますが、実際にはテクニカルSEOのとても重要な基本設定です。

これは企業が混同しやすい考え方です。

Google があるページをクロールできることは、

そのページが Google のインデックスに必ず入ることを意味しません。

たとえば、

ページに noindex が設定されている場合があります。

あるいは、Google がクロールを終えたうえで、そのページをインデックスに入れないと判断することもあります。

つまり 「クロール ≠ インデックス」 であり、

「インデックス ≠ 順位の保証」 です。

テクニカルSEOは検索エンジンがサイトを正しく処理する手助けにはなりますが、「技術設定がすべて正しければ、Google が必ずインデックスし、順位を付ける」 ことまでは保証できません。

企業サイトは、次のような理由で

似た URL がいくつもできてしまいがちです。

そうなると、検索エンジンはどれがメインのバージョンかを判断しなければならなくなります。

テクニカルSEOでは、次の手段で

より一貫した URL シグナルをつくれます。

私たちのプラットフォームも同じ方針をとっています。たとえば canonical には、あとでまたリダイレクトされる中間の URL ではなく、正規の公開 URL を使います。サイトマップも同様に正規の公開 URL を出力します。

ごく小さな技術的な細部に見えますが、要は自分のサイトが検索エンジンに複数の違う答えを同時に伝えないようにすることです。

テクニカルSEOは、リニューアルのときに特に重要になります。

たとえば、すでに順位と外部リンクを獲得している URL /seo-guide が、

リニューアル後に /resources/seo-guide になったとします。

旧 URL に手を打たなければ、ユーザーも検索エンジンもいきなり 404 Not Found にぶつかるかもしれません。

より妥当なのは、たいてい新旧ページの対応関係を整理し、必要に応じて恒久的なリダイレクトを設定することです。

つまり、リニューアルでは 「新しいサイトが正常に開くか？」 を確認するだけでは足りません。

旧サイトに蓄積された URL と検索資産をどう移行するかも確認する必要があります。

だからこそ、SEO 移行はそれ自体がリニューアルの重要な作業なのです。

十数ページしかない小さなサイトなら、多くの SEO の問題は手作業で確認できます。

しかし、サイトに次のようなものが増えてくると、

テクニカルSEOの設定をすべて手作業に頼っていては、ミスが起きやすくなります。

そのため成熟したプラットフォームでは、標準化できることは仕組みとして処理するのが一般的です。

たとえば私たちのプラットフォームでは、コンテンツのスラッグを変更すると、旧 URL から新 URL への恒久的なリダイレクトを作成します。サイトマップも、管理者に XML を手作業で保守させるのではなく、実際の公開状態とインデックス設定にもとづいて動的に生成します。

このやり方の最大の価値は 「SEO 機能が多いこと」 ではありません。

サイトを長く運用するなかで、テクニカルSEOのミスが起きる確率を下げることです。

最後に、反対側の極端も避けましょう。「テクニカルSEOは完璧だから、コンテンツは重要ではない」 という考え方です。

たとえば、

という状態でも、サイトのコンテンツが検索ニーズに本当に応えていなければ、それだけで良い検索順位が得られるわけではありません。

逆に、非常に良いコンテンツ + 深刻なテクニカルSEOの問題

という組み合わせも、コンテンツの検索でのパフォーマンスを制限しかねません。

ですから、より妥当な関係は次のとおりです。

両者は互いの代わりになるものではなく、SEO 戦略の異なる土台です。

SEO の作業は多岐にわたるため、「テクニカルSEO、オンページSEO、オフページSEO」 という 3 つの分類をよく目にします。

これらは互いに独立した 3 つの SEO 手法ではなく、それぞれ異なる層の問題を扱っています。

もっとも簡単な捉え方は次のとおりです。

テクニカルSEOが主に扱うのは、検索エンジンがサイトにどうアクセスし、どう処理するかです。

代表的な項目は次のとおりです。

たとえば、

サイトにとても良い記事があるのに、誤って noindex が設定されているとします。

これは記事の書き方が悪いのではなく、テクニカルSEOの問題です。

あるいは、リニューアルで大量の URL が変わったのに、正しいリダイレクトを設定していない場合。

これもテクニカルSEOの領域です。

オンページSEO は、主にサイトのページ内のコンテンツと最適化できる要素を対象にします。

たとえば、

ユーザーが 「SEO 記事はどう書く？」 と検索したのに、

ページの大半が 「なぜ企業に SEO が必要なのか？」 の説明だったとします。

テクニカルSEOがまったく問題なくても、このページは検索意図を十分に満たしていない可能性があります。

これは、どちらかといえば オンページSEO／コンテンツ SEO で扱う問題です。

オフページSEOは、自社サイトの外で起きることです。

もっとも代表的な項目は被リンク（Backlinks）です。

たとえば、関連性のあるほかのサイトが、自分たちのコンテンツであなたの調査、記事、ツールを引用し、あなたのサイトへリンクを張るケースです。

このほか、オフページSEOには次のようなものも含まれます。

ただし、ここで特に注意したい点があります。

オフページSEO ≠ 外部リンクを大量に買うこと。

検索順位を操作する目的でリンクを購入・交換・大量作成すると、Google のリンクスパムに関するポリシーに抵触するおそれがあります。

ですから企業にとっては、オフページSEOをほかのサイトに言及・引用してもらえるブランドとコンテンツの資産を築くことと捉えるほうが適しています。

できるだけ多くの被リンクを手に入れる方法を考えることではありません。

SEO をこの 3 つに分けることはできますが、実際の取り組みでは完全に切り離されているわけではありません。

たとえば、

企業がとても良い調査記事を公開したとします。

オンページSEO → 検索ニーズ、内容、タイトル、見出しはどれもよくできている。

しかし テクニカルSEO → ページに誤って noindex が設定されている。

それでは、コンテンツが検索結果にまったく表示されないかもしれません。

逆に、

テクニカルSEOはまったく問題ないのに、コンテンツの品質が低い場合。

これも 「サイトの技術が優れているから、自然に順位が付く」 という意味にはなりません。

また、独自の調査や業界にとっての価値が本当にある記事は、ほかのサイトに引用され、さらに次のものを生むことがあります。

オフページSEOとしての自然な被リンク。

つまり、3 つには次のような関係があります。

これも分類するときによくぶつかる疑問です。

答えは、どちらにも関係するです。

ですから、「この項目はどれかひとつの分類にしか入らないのか？」 と深く悩む必要はありません。

SEO の分類は主に問題を理解するためのもので、厳密な技術上の境界ではありません。

テクニカル → オンページ → オフページ という決まった順番で、

ひとつを完全に終えてから次に進む、というものではありません。

より妥当なのは、まず SEO を妨げる重大な技術上の問題がないか を確認することです。

たとえば、

こうした問題は優先して対処すべきです。

サイトに基本的に健全な技術基盤があることを確認できたら、コンテンツ、オンページSEO、オフページSEOを継続して進められます。

つまり、テクニカルSEOはサイト SEO のインフラのようなものです。

一度やれば二度と手をかけなくてよいものではなく、サイトが機能を追加し、コンテンツを増やし、リニューアルし、ドメインを変え、言語を増やすのに合わせて継続的に保守していくものです。

テクニカルSEOを理解するには、まず Google がサイトをどう処理しているかを理解する必要があります。

多くの人は、Google がサイトを見る → サイトが検索結果に表示される をひとつのステップだと考えがちです。

しかし実際には、その間にいくつかの段階があります。

ひとまず、次のように単純化して捉えられます。

Discovery（URL の発見）

↓

Crawling（クロール）

↓

Rendering（レンダリング）

↓

Indexing（インデックス）

↓

Serving（検索結果への表示）

段階ごとに扱う問題が異なり、対応するテクニカルSEOの課題も異なります。

クロールの前に、Google はまず その URL が存在すること を知る必要があります。

Google は、たとえば次のような方法で URL を発見します。

たとえば、企業が新しい記事 /blog/technical-seo を公開したとします。

トップページ、記事一覧、カテゴリページ、ほかのコンテンツからきちんとリンクされていれば、Google はそのリンクをたどって新しい URL を発見できます。

XML サイトマップでも、検索エンジンに知ってほしい重要な URL を伝えられます。

つまり、内部リンクもサイトマップも URL の発見に影響します。

ただし、Google が URL を発見してもクロールするとは限らず、クロールしてもインデックスするとは限りません。

これらの考え方は分けて理解する必要があります。

Google が URL を発見すると、Googlebot はその URL へのアクセスを試みることがあります。

この過程を クロール（Crawling） と呼びます。

リクエストを受けたサーバーは、次のものを返します。

などのリソースです。

ここから、テクニカルSEOは次のような点にかかわってきます。

たとえば /important-page は実際に存在しているのに、robots.txt が Googlebot のクロールを禁止している場合です。

そうなると、Google はこのページの内容を正しく取得できないかもしれません。

つまり、クロールの段階で問われるのは次のことです。

従来の HTML サイトでは、ページの主要なコンテンツをたいていサーバーから直接取得できます。

しかし、最近のサイトは JavaScript を多用しています。

サイトによっては、最初に返される HTML にはほとんど内容がなく、実際の

は、ブラウザが JavaScript を実行してはじめて生成されます。

ここでかかわるのが レンダリング（Rendering） です。

Google は JavaScript を実行してページをレンダリングできますが、だからといって企業が JavaScript SEO をまったく考えなくてよいわけではありません。

より重要なのは、主要な SEO コンテンツを Google が正しく取得・レンダリングできるかどうかを確認することです。

ここでフロントエンド技術をすべて理解する必要はありません。押さえておきたい核心的な違いはひとつだけです。

この 3 つの方式は、どれも「それを使えば必ず SEO に有利」というものではありません。

本当に確認すべきなのは、Google がページの主要なコンテンツとリンクを安定して取得できるかどうかです。

TimTech のプラットフォームは現在 Next.js App Router を使っており、公開ページは Server Component + Client Component の混在構成で処理しています。

主要な SEO コンテンツ、たとえば

は、主に Server Component が出力します。

インタラクティブな機能、たとえば

だけを Client Component に任せています。

そのため、ユーザーが JavaScript を無効にしていても、主要なテキストは HTML の中に存在します。JavaScript が担うのは主にインタラクションで、SEO の本体となるコンテンツをまるごとブラウザ側で生成させるわけではありません。

これはとても実用的なテクニカルSEOの原則です。重要なコンテンツを、必要もないのにクライアントサイドの JavaScript だけに頼って表示させないこと。

Google がページをクロールして内容を処理したあと、次に進む可能性があるのが

インデックス（Indexing） です。

Google はページの次のような要素を分析します。

そのうえで、ページを検索インデックスにどう組み込むかを判断します。

ここでもう一度強調しておきます。クロールに成功 ≠ 必ずインデックスされる。

たとえば、ページに noindex が設定されていれば、

検索エンジンに このページを検索インデックスに入れないで とはっきり伝えていることになります。

また、サイトがインデックスを許可していても、Google がすべてのページをインデックスに入れるとは限りません。

ですから、「サイトマップはもう送信したのに、なぜ Google にインデックスされないのか？」 という疑問は、

そもそも サイトマップ → インデックス を必ず成り立つ関係だと誤解しています。

サイトマップは Google が URL を発見・理解する助けにはなりますが、ページがインデックスされることは保証できません。

ページが Google のインデックスに入ったあと、ユーザーが検索したときにはじめて、Google は次の要素をもとに

どの検索結果を表示し、どう並べるかを決めます。

つまり、インデックス ≠ ランキングです。

これも、テクニカルSEOにとって重要な境界線です。

テクニカルSEOは、サイトが正しいクロール、レンダリング、インデックスの土台を築く助けになります。

しかし、そこから「テクニカルSEOをすべてやれば、Google は必ずサイトを 1 位にする」と結論づけることはできません。

実際の検索順位には、コンテンツ、関連性、品質、サイトや外部のシグナルなど、さらに多くの要素がかかわります。

次のように整理すると、すばやく把握できます。

ですから、企業が 「このページが Google で見つからない」 と気づいたとき、

すぐに 「記事の SEO の書き方が悪いのでは？」 と判断すべきではありません。

まず、問題が実際にどの段階で起きているのかを突き止めるべきです。

テクニカルSEOがカバーする範囲は広いものの、互いに無関係な技術設定の寄せ集めだと考える必要はありません。

理解しやすいのは、前に説明した検索エンジンの流れに立ち返ることです。

検索エンジンはページを見つけられるか？

↓

正常にクロールできるか？

↓

コンテンツを取得し、理解できるか？

↓

インデックスすべきか？

↓

どの URL が正規のバージョンか？

↓

サイトはわかりやすく一貫した技術シグナルを送っているか？

この観点から、企業サイトでよくあるテクニカルSEOの作業は、次の 14 のポイントに整理できます。

テクニカルSEOでもっとも基本となる最初のことは、検索エンジンが重要なページに正常にアクセスできるかどうかです。

Googlebot がページを取得できなければ、その後の

も、うまく機能しないかもしれません。

そのため、次の点を確認する必要があります。

テクニカルSEOの監査も、たいていはサイトがそもそも正常にクロールできるかの確認から始めます。

robots.txt はサイトのルートディレクトリに置くファイルで、検索エンジンのクローラーにサイトのどのパスのクロールを許可し、どのパスを許可しないかを伝えます。

たとえば、

これは、一般的な検索エンジンのクローラーに /admin/ をクロールしないよう求めるという意味です。

ただし、とても重要な考え方がひとつあります。

あるページを本当に検索インデックスに入れたくないなら、通常は noindex を使うべきです。

robots.txt だけに頼るべきではありません。

この違いは、あとで改めて説明します。

XML サイトマップでは、検索エンジンにサイトのどの重要な URL を発見・クロールしてほしいかを伝えられます。

たとえば、企業サイトには次のようなページがあります。

こうした正式な公開ページは、サイトマップにまとめられます。

ただし、サイトマップは 「送信すれば Google が必ずインデックスする」 ものではありません。

主に URL の発見を助け、サイトの情報を伝えるための仕組みです。

私たちのプラットフォームでも、システム上のすべての URL を入れるのではなく、実際に公開されインデックスを許可したコンテンツにもとづいてサイトマップを動的に生成しています。

サイトには存在が必要なページもありますが、それらがすべて Google の検索結果に表示されるべきだとは限りません。

たとえば、

このような場合は、次のように記述する必要があるかもしれません。

これにより、この指示に対応している検索エンジンにこのページを検索インデックスに入れないよう伝えます。

つまり、

クロールできること と インデックスを許可すること は別のことです。

同じ、あるいは非常によく似たコンテンツに複数の URL からアクセスできる場合にかかわってくるのが canonical です。

たとえば /product?id=123 と /products/example が、ほぼ同じ内容を表示していることがあります。

次のように記述すると、

どの URL が優先されるメインのバージョンか というシグナルを検索エンジンに伝えられます。

ただし、canonical はリダイレクトではなく、Google に 「必ずこの URL だけを使え」 と強制するものでもありません。

canonical 化（正規化）のための重要なシグナルのひとつです。

HTTP ステータスコードは、ブラウザと検索エンジンに この URL へのリクエストで何が起きたか を伝えます。

テクニカルSEOでよく出てくるのは次のものです。

正しいステータスコードは、その URL がいまどんな状態にあるのか を検索エンジンが理解する助けになります。

URL を恒久的に変更するときは、通常 恒久的なリダイレクト（Permanent Redirect） の設定を検討する必要があります。

たとえば、

/old-seo-guide

↓

/seo-guide

こうすれば、旧 URL にアクセスしたユーザーと検索エンジンを、新しい正規 URL へ案内できます。

私たちのプラットフォームでは、記事、商品、カテゴリのスラッグを変更すると、元の URL をそのまま 404 にするのではなく、旧 URL を残して恒久的なリダイレクトを自動で作成します。

ただし、リダイレクトを乱用してはいけません。

たとえば A → B → C → D のように、

リダイレクトチェーンが長くなりすぎている場合は、サイトの長期的な URL 管理を整理する必要があるかもしれません。

サイトの URL は、ユーザーと検索エンジンがコンテンツの構造を理解しやすいものであるべきです。

たとえば /resources/seo/technical-seo は、

たいてい /page?id=93847&type=12 よりも

理解しやすいものです。

ただし、テクニカルSEOは URL にキーワードをたくさん詰め込むこと を求めているわけではありません。

本当に重要なのは次の点です。

内部リンクはコンテンツ SEO だけのものではありません。

検索エンジンがサイトのページをどう発見し、サイトの情報構造をどう理解するかにも影響します。

たとえば、

トップページ

↓

SEO ソリューション

↓

SEO 完全ガイド

↓

SEO キーワードリサーチ

↓

SEO 記事の書き方

こうした通常の HTML リンクによって、検索エンジンはサイトの構造をたどってコンテンツを発見できます。

ですから、重要なページを サイト内のどのページからもリンクされていない孤立ページ（Orphan Page） にしてはいけません。

最近のサイトでは、次のような技術が多用されています。

そのため、検索エンジンが JavaScript のサイトから主要なコンテンツとリンクを正しく取得できるかを確認する必要があります。

本当に注意すべきなのは 「JavaScript を使うと SEO に悪い」 ということではありません。

重要なコンテンツがクライアントサイドレンダリングに頼りすぎていないか、そして Google が最終的なコンテンツを安定して取得できるかです。

私たちのプラットフォームでは現在、公開コンテンツは主に Server Component が HTML として出力し、インタラクティブな機能は Client Component が処理しています。機能とインデックス可能なコンテンツの役割を分けているわけです。

Google はモバイルファーストインデックスを採用しているため、サイトのモバイル版のコンテンツはとても重要です。

企業は次の点を確認すべきです。

テクニカルSEOは 「スマートフォンでレイアウトが崩れて見えない」 だけでは足りません。

モバイル版でも重要なコンテンツをすべて提供しているかも確認する必要があります。

企業サイトは HTTPS を使って暗号化された接続を提供すべきです。

セキュリティに加えて、http://example.com と https://example.com という

どちらも閲覧できる 2 つの正式バージョンが同時に存在する状態も避ける必要があります。

通常は、一貫した HTTP → HTTPS のリダイレクトと canonical のシグナルを設定すべきです。

私たちのプラットフォームでも、カスタムドメインの TLS / SSL は Vercel が自動で処理し、HTTP を HTTPS にリダイレクトしています。

構造化データは標準化された形式を使い、ページ内のエンティティや情報を検索エンジンがより明確に理解できるようにするものです。

よく使われるものには、次のようなものがあります。

よく使われる実装形式は JSON-LD です。

ただし、特に注意してください。構造化データ ≠ リッチリザルトの保証 ≠ スキーマを加えれば検索順位が直接上がる。

より重要なのは、スキーマがページに実際に表示されている内容と一致していなければならないことです。

たとえば私たちのプラットフォームでは、商品に実際の価格がなく「見積依頼」形式の場合、スキーマを埋めるために Offer の価格をでっち上げることはしません。

これは「スキーマの項目は多く埋めるほど良い」ということより重要です。

最後は、企業がもっともテクニカルSEOと同一視しがちなサイトの速度です。

Google の Core Web Vitals は、現在主に次の 3 つで構成されています。

サイトのパフォーマンスは確かに改善する価値があります。

しかし、PageSpeed Insights の 100 点を

テクニカルSEOの最終目標にしてはいけません。

本当に注意すべきなのは、サイトが実際に良い利用体験を提供していて、深刻なパフォーマンスの問題がないかどうかです。

このリストを見ると、テクニカルSEOをまた 14 項目の SEO チェックリスト にしてしまいがちです。

しかし本当に重要なのは、これらの設定どうしの関係を理解することです。

たとえば、サイトマップ はこの URL が重要だと言っているのに、

noindex はインデックスしないでと言っている。

あるいは、canonical は URL A を指しているのに、

URL A は URL B にリダイレクトしている。

どちらも、サイト自身が一貫しない技術シグナルを送っていることを意味します。

ですから、テクニカルSEOが本当に目指すべきなのは次のことです。

robots.txt はサイトのルートディレクトリに置くテキストファイルで、検索エンジンのクローラーにサイトのどのパスのクロールを許可し、どのパスを許可しないかを伝えるものです。

たとえば、

これは、ルールに従うすべての検索エンジンのクローラーに /admin/ パスをクロールしないよう求めるという意味です。

つまり、robots.txt が主に扱うのは 検索エンジンがサイトをクロールする動き であり、

ページが Google のインデックスに必ず表示されるかどうかを制御すること ではありません。

この 2 つの考え方はとても重要です。

企業サイトは、検索エンジンに大量にクロールされたくない領域を robots.txt で管理できます。

たとえば、

robots.txt には、たとえば次のようにサイトマップの場所を記載することもできます。

検索エンジンは、ここからサイトマップの場所を取得できます。

私たちのプラットフォームでも robots.txt を動的に生成しています。初期設定では公開コンテンツのクロールを許可し、/admin/、/api/、/preview/、/``_next/ などのシステムパスをブロックしたうえで、サイトマップの URL を記載しています。

これは robots.txt についてもっともよくある SEO の誤解のひとつです。

たとえば、企業に /private-page というページがあり、

次のように設定したとします。

これが意味するのは、この URL をクロールしないよう検索エンジンに求めることです。

しかし、「Google はこの URL を検索結果に絶対に表示しない」 と単純に受け取ることはできません。

Google が外部リンクなど別の場所からこの URL を知った場合、URL は発見されることがあります。

ですから、誰でもアクセスできるページを本当に Google のインデックスに入れたくないなら、通常は次のように記述すべきです。

robots.txt だけに頼るべきではありません。

ここにも、とても重要なテクニカルSEOのロジックがあります。

たとえば、ページ自体に次の設定をしているのに、

robots.txt でも次のように設定しているとします。

これは問題を引き起こすことがあります。

理由は、Google はページをクロールしてはじめて、ページ内の noindex の指示を確認できるからです。

robots.txt ですでに Google のクロールをブロックしていると、Google はページ内の noindex を読み取れない可能性があります。

ですから、目的が 「Google のアクセスは許可するが、ページはインデックスに追加しない」 ことなら、

より合理的なのは クロールを許可 + noindex であり、

Disallow + noindex ではありません。

これが、企業が クロールの制御 と インデックスの制御 を分けて理解する必要がある理由でもあります。

もうひとつよくある間違いは、robots.txt を非公開のコンテンツを守る方法として使うことです。

たとえば、

と書いても、ユーザーが example.com/confidential/ を直接入力してページを開けなくなるわけではありません。

robots.txt 自体が公開ファイルで、誰でも見ることができます。

ですから、コンテンツが本当に次のようなものなら、

認証（Authentication）、認可（Authorization）、その他の本当のアクセス制御で守るべきです。

robots.txt に頼るべきではありません。

サイトによっては、「Google にあまりクロールさせたくない」 という理由で、

CSS、JavaScript、その他のリソースを大量にブロックしています。

しかし、検索エンジンがページを正しくレンダリングするには、これらのリソースが必要な場合があります。

ですから、「記事のコンテンツではないから」 という理由だけですべてを Disallow すべきではありません。

本当に確認すべきなのは、Google がページを正しく理解しレンダリングするためにこれらのリソースを必要としているかどうかです。

一般的な企業サイトなら、robots.txt はたいていそれほど複雑にする必要はありません。

合理的な原則は次のとおりです。

この 4 つのケースを混同しないでください。

もっとも深刻なのは、誤って本番サイト全体をブロックしてしまうケースです。

たとえば、

は、検索エンジンに サイト全体をクロールしないよう求める という意味です。

この設定は ステージング／テスト環境 で使われていることがあります。

サイトを本番公開したあとに削除し忘れると、深刻な SEO の問題につながりかねません。

ですから、サイトの公開時やリニューアル時には、robots.txt をテクニカルSEOのチェック項目に入れるべきです。

現在、私たちのプラットフォームの robots.txt は システムが合理的な初期設定を生成 + テナントが追加のルールを設定できる

という方式です。

システムは、管理画面や API のブロックなど必要なテクニカルSEOのルールを保持します。ユーザーは独自の Disallow / Allow ルールを追加できますが、システムの保護ルールを上書きすることはできません。

目的はユーザーを制限することではなく、robots.txt の設定ミスによってサイト全体のテクニカルSEOの土台を壊してしまう

リスクを下げることです。

XML サイトマップは、検索エンジンに提供するサイトの URL の一覧で、検索エンジンが次のことを理解する助けになります。

サイトのどの重要なページを発見・クロールしてほしいか。

たとえば企業サイトには、次のようなページがあるでしょう。

こうした正式に公開されていて検索価値のある URL は、すべて XML サイトマップに含められます。

よくある URL は https://example.com/sitemap.xml です。

前に触れたとおり、Google は次のような経路で

新しい URL を発見します。

ですから、サイトマップの主な価値のひとつは次の点です。

特に、サイトの規模が大きい、コンテンツの更新が頻繁、あるいはサイトのナビゲーションから一部のページがすぐには見つけにくいといった場合に、サイトマップはより役立ちます。

これも企業によくある誤解です。

URL をサイトマップに入れても、

サイトマップが伝えるのは 「これらはサイトが検索エンジンに知ってほしい重要な URL です」 ということです。

それでも、クロールやインデックスをするか、これらのページをどう扱うかは Google が自分で判断します。

ですから、Search Console に Sitemap Submitted Successfully と表示されても、

「SEO のインデックス登録は完了した」 と受け取ることはできません。

実際のページのインデックス登録（Page Indexing）の状況を、さらに確認する必要があります。

とても実用的な原則があります。

たとえば、

入れるのに適したもの

通常入れるべきでないもの：

サイトマップが Google に 「これは重要な正式 URL です」 と伝えているのに、

ページ自体が Google に 「インデックスしないで」 と伝えていれば、

サイトは互いに矛盾するシグナルを送っていることになるからです。

たとえば、サイトに https://example.com/product-a があり、

そのページの canonical が https://example.com/products/product-a だとします。

その場合、サイトマップに載せるのは https://example.com/products/product-a、

つまり canonical URL のほうが合理的です。

同じように、/old-page が

すでに /new-page へ恒久的にリダイレクトしているなら、

サイトマップには /new-page を直接載せるべきで、

旧 URL を残し続けるべきではありません。

つまり、サイトマップは 「サイトのすべての URL を並べたもの」 ではありません。

サイトが検索エンジンに処理してほしい正式な URL の一覧であるべきです。

XML サイトマップでは <lastmod> も指定でき、

ページの内容が最後に大きく更新された日時を示すのに使います。

たとえば、

ただし lastmod を、サイトマップを再生成するたびに全部今日の日付に更新するものにしてはいけません。

そうすると「コンテンツが実際に更新された日時」という意味がなくなってしまうからです。

私たちのプラットフォームでも、サイトマップがリクエストされるたびに全ページの日付をその日に書き換えるのではなく、コンテンツの実際の updated``_at から lastmod を生成しています。

小さいけれど重要な実装上の細部です。情報を提供するなら、その情報自体が信頼できるものであるべきです。

多言語サイトでは、各言語バージョンの URL を並べるだけでなく、hreflang を使って

異なる言語や地域のバージョンどうしの関係を示すこともできます。

たとえば、

これらは互いに無関係な 3 つのページではなく、同じコンテンツの異なる言語バージョンである可能性があります。

私たちのプラットフォームでは、サイトマップに言語バージョンの情報を出力し、対応する hreflang の関係も含めています。

International SEO については、後ほど詳しく説明します。

最近の CMS や動的なサイトでは、サイトマップを手作業で管理することはおすすめしません。

たとえば、企業に 500 本の記事 + 300 点の商品 + 3 つの言語 があるとします。

次のようなことをするたびに、

サイトマップを手作業で修正していては、ミスが起きやすくなります。

より合理的なのは、サイトのシステムがコンテンツの実際の状態に基づいてサイトマップを動的に生成することです。

私たちのプラットフォームでは現在、次の情報に基づいて

サイトマップを自動で生成しています。

このように明確にルール化できるテクニカルSEOの作業は、システムに任せるのに向いています。

厳密に言えば、すべてのサイトが Google に発見・インデックスされるためにサイトマップを必要とするわけではありません。

サイトが次のような状態なら、

Google はそれでもサイトのコンテンツを問題なく発見できる可能性があります。

ですから、サイトマップは 「なければ SEO ができない」 というものではありません。

ただ、一般的な企業サイトにとって、サイトマップを作るコストはとても低く、検索エンジンにより明確な URL の情報を提供できます。

特に、次のようなサイトでは

作る価値がより高くなります。

ですから、私たちの実務上のおすすめはやはりシンプルです。

ポイントは「ないと順位がつかない」ということではなく、コストが低く、標準化しやすく、検索エンジンが重要な URL を発見する助けになるテクニカルSEOの基礎だということです。

サイトマップを作成したら、次の場所から送信できます。

Google Search Console → Sitemaps

そのあと、Google がサイトマップを正しく読み取れているかを確認できます。

ただし、サイトマップが正常に読み取られたこと と サイトのページが正常にインデックスされたこと は別のものだと覚えておいてください。

インデックスの状況を本当に判断するには、ページのインデックス登録レポート（Page Indexing Report）と URL 検査（URL Inspection）をあわせて確認する必要があります。

canonical URL は、検索エンジンに次のことを伝えるシグナルです。

複数の URL に同じ、またはよく似たコンテンツがあるとき、どの URL がサイトの優先する主要バージョンなのか。

通常は HTML の中で次のように設定します。

この URL は通常 canonical URL（正規 URL／主要バージョンの URL） と呼ばれます。

企業が意図して重複コンテンツをつくっているとは限りません。

多くの場合、サイトのシステムが自然に別の URL を生成しています。

たとえば、

これらの URL が同じ、またはとてもよく似たコンテンツを提供しているなら、正規化（Canonicalization） が関わってくる可能性があります。

ページに明らかな重複バージョンがなくても、正式なページが自分自身を指すように設定できます。

たとえば、現在の正式 URL が https://example.com/technical-seo なら、

次のように設定します。

これを 自己参照 canonical（Self-referencing Canonical） と呼びます。

これにより、サイトは 「これがこのページの正式 URL です」 とより明確に伝えられます。

TimTech のプラットフォームでもこの方式を採用しており、ページの正式な公開 URL に基づいて canonical を自動生成しています。

この 2 つの考え方は混同されやすいものです。

たとえば、URL A と URL B があるとします。

ユーザーは引き続き A にアクセスできます。

ただし、A は検索エンジンに 「B が私の優先する主要バージョンです」 と伝えます。

ユーザーが A にアクセスすると、そのまま B へ移動します。

ですから、旧 URL がすでに新しい URL へ恒久的に置き換えられているなら、

通常は 恒久的なリダイレクト を検討すべきです。

サイトの機能上、複数の URL を残す必要があるものの、内容がよく似ているなら、

canonical が適しているかもしれません。

この 2 つをまったく同じ道具として扱うことはできません。

もうひとつ重要な考え方があります。Google はサイトが指定した canonical を必ず採用するとは限りません。

Google は、次のようなさまざまなシグナルを総合して主要バージョンを判断します。

そのため、Google Search Console では User-declared canonical と Google-selected canonical が表示されることがあり、

両者が一致するとは限りません。

Google が長期にわたって別の canonical を選んでいるなら、サイトが互いに矛盾するシグナルを送っていないかを確認すべきです。

たとえば、サイトが /new-page を canonical に指定しているとします。

ところが、サイトマップ にはまだ /old-page が載っていて、

内部リンク も大量に /old-page を指しているのに、

canonical は /new-page を指している。

この場合、サイト自身が別々の答えを示していることになります。

理想的なのは次の状態です。

Canonical

→ /new-page

Sitemap

→ /new-page

Internal Linking

→ /new-page

旧 URL がすでに恒久的に置き換えられているなら、

Redirect

→ /new-page

主要なシグナルをできるだけ一致させます。

これは単に 「canonical タグを入れたかどうか」 よりも重要です。

これは、私たちがプラットフォームを実装するなかで、ぜひ共有したい細部のひとつです。

たとえば、本当の正式 URL が https://example.com/zh-TW/about なのに、

canonical には https://example.com/about と書かれていて、

その /about がさらに /zh-TW/about へリダイレクトしているとします。

すると canonical → リダイレクト → 最終 URL という形になります。

よりすっきりしたやり方は、canonical が最終的な正式 URL を直接指すことです。

そのため、私たちのプラットフォームでは canonical を生成するとき、あとでリダイレクトされる中間の URL ではなく、テナントの正式な公開 URL とロケールのパスを直接使っています。

この原則は、次のものにも当てはまります。

SEO のシグナルは、できるだけ最終的な正式 URL を直接指すようにします。

ここもよく設定を間違えるところです。

たとえば、

この 3 つのページが本当に言語の異なるコンテンツのバージョンなら、通常は 英語版と日本語版の canonical をすべて中国語版に向ける べきではありません。

そうすると、検索エンジンに 中国語版こそが主要バージョンだ と伝えることになりかねません。

より合理的なのは、通常 各言語バージョンを Self-canonical にし、

hreflang で言語バージョンどうしの関係を示すやり方です。

私たちのプラットフォームでも、canonical は現在の言語自身の正式 URL を指し、

別途 hreflang + x-default を生成しています。

この点は、後ほど International SEO の章で詳しく扱います。

canonical は重要ですが、URL の問題をすべて canonical に任せてはいけません。

たとえば、

つまり、canonical は正規化の道具のひとつであって、サイトの重複コンテンツの問題を何でも解決する方法ではありません。

企業サイトは、特に次の点に注意するとよいでしょう。

これらの問題に共通する核心は、どの URL が正式バージョンなのかを、サイトが検索エンジンに明確かつ一貫して伝えていないことです。

検索エンジンが URL をクロールするとき、サイトはコンテンツだけでなく HTTP ステータスコード（HTTP Status Code）も返します。

これは、ブラウザと検索エンジンに この URL へのリクエストの結果がどうだったか を伝えるものです。

テクニカルSEOでよく出てくるステータスは次のとおりです。

これらのステータスコード自体は「SEO のスコア」ではありませんが、検索エンジンが URL をどう理解し処理するかに影響します。

200 OK は、サーバーがこのページを正常に返したことを意味します。

正式な公開ページは、通常 200 を正常に返すべきです。

ただし、200 ≠ Google に必ずインデックスされる、です。

たとえば、ページが 200 を返していても、次のような場合があります。

つまり、HTTP ステータスコードが扱うのは URL へのリクエストの状態 です。

検索順位やインデックスの結果を直接決めるものではありません。

ある URL が恒久的に変わったときは、恒久的なリダイレクト（Permanent Redirect） を使えます。

たとえば、元の URL が /seo-guide-old で、

現在の正式 URL が /seo-guide になったとします。

ユーザーや検索エンジンが旧 URL にアクセスすると、

Old URL → Permanent Redirect → New URL

となり、このリソースは新しい URL へ恒久的に移転したことをはっきり示せます。

よく使われる恒久的なリダイレクトのステータスには、301 と 308 があります。

どちらも恒久的な転送を表せます。違いは主に HTTP リクエストメソッドの扱い方にあります。

一般的な SEO の URL 移行で本当に重要なのは、サイトが正しい恒久的なリダイレクトを使っているか、そして転送先が妥当かです。

たとえば、企業に 2 年前からある記事があり、

/seo-guide がリニューアル後に /resources/seo-guide になったとします。

旧 URL をそのまま削除して /seo-guide → 404 にすると、

次のものが

すべて存在しないページにつながってしまう可能性があります。

新しいページが本当に旧コンテンツの代わりになるなら、通常より合理的なのは次のやり方です。

旧 URL → Permanent Redirect → 新 URL

これは SEO の移行（SEO Migration）でとても重要な部分です。

私たちのプラットフォームでは、記事、商品、カテゴリのスラッグを変更すると、旧スラッグを自動で記録し、新しい正式 URL への 308 Permanent Redirect を作成します。

このように新旧 URL の関係をはっきり判断できるものは、システムが自動で処理するのに向いています。

URL の変更が一時的なものにすぎないなら、一時的なリダイレクト（Temporary Redirect） を使えます。

よく使われるのは 302 と 307 です。

たとえば、キャンペーンやメンテナンスのために一時的に別の URL へ案内する必要があるものの、いずれ元の URL に戻す予定なら、一時的なリダイレクトを使うことがあります。

ですから、「リダイレクトは全部 301」 と機械的に決めないでください。

まず、今回の URL の変更が恒久的なのか一時的なのかを判断すべきです。

404 Not Found は、サーバーがこの URL に対応するリソースを見つけられないことを示します。

多くの企業は、Search Console に 404 が出ると 「サイトの SEO に問題がある。404 はすべて直さなければ」 と考えます。

実はそうではありません。

ページが次のような状態なら、

404 を返すこと自体はまったく妥当です。

本当に対処すべきなのは、重要なページが意図せず 404 になってしまうことです。

たとえば、

こうしたケースこそ、優先して確認する価値があります。

これもサイトのリニューアルでよく見られるやり方です。

存在しない旧 URL が大量に見つかると、そのまま次のように設定してしまいます。

すべての 404 → トップページ

一見、「少なくともユーザーはエラーページを見ずに済む」 ように思えます。

しかし問題は、

元の /old-product-a が

トップページとは内容的にまったく関係ないかもしれないことです。

妥当なリダイレクトは、旧コンテンツ → 本当に対応する新しいコンテンツ であるべきです。

妥当な代わりのページがまったくないなら、通常どおり 404 や 410 を返すほうが、

たいていはかえってわかりやすくなります。

つまり、リダイレクトの核心は 「404 を出さないこと」 ではありません。

「新旧の URL の間に本当に妥当な対応関係があるかどうか」 です。

410 Gone は、このリソースは以前は存在したかもしれないが、現在は明確に削除されていることを示します。

404 とは意味が少し異なります。

私たちのプラットフォームでは、削除済みの記事や商品に対して、本当の 410 Gone を返せます。

エラーページのように見えるだけの 200 OK のページで置き換えるのではありません。

ここから、もうひとつ重要な問題が見えてきます。ソフト 404（Soft 404） です。

ユーザーが存在しないページにアクセスしたとします。

画面には 「このページは見つかりません」 と表示されます。

ところが、サーバーが実際に返しているのは 200 OK です。

この場合、ソフト 404 になる可能性があります。

つまり、コンテンツは存在しないように見えるのに、HTTP レスポンスは検索エンジンにページは正常だと伝えている状態です。

ですから、テクニカルSEOでは 「画面に 404 と表示されているか」 だけを見てはいけません。

サーバーが実際に返している HTTP ステータスコードが正しいかどうかも確認する必要があります。

5xx は、サーバー側で問題が起きていることを表します。

たとえば、

ときどき一時的なサーバーエラーが起きても、サイトの SEO がすぐに大きな影響を受けるわけではありません。

しかし、Googlebot がサイトをクロールするたびに長期間・大量に 5xx に遭遇しているなら、検索エンジンがサイトのコンテンツを安定して取得できていないことを意味します。

その場合に本当に対処すべきなのは、次のような点です。

記事の SEO を手直しすることではありません。

たとえば、

URL A

↓

URL B

↓

URL C

↓

URL D

という リダイレクトチェーン（Redirect Chain） ができているとします。

URL を長期にわたって何度も変更していると、こうした状態が積み重なりやすくなります。

より良いやり方は A → D です。

旧 URL は、できるだけ最終的な正式バージョンへ直接リダイレクトさせます。

私たちのプラットフォームのスラッグのリダイレクトの仕組みは、最終的な転送先を調べることで、リダイレクトチェーンができる可能性を下げています。

これが、URL 管理が 「リダイレクトがあれば十分」 というだけではない理由でもあります。

リダイレクトが最終的にどこへ案内しているのかも確認する必要があります。

まずは、次のシンプルな原則を使えます。

本当に重要なのは次の点です。

SEO のためにすべてのページがなんとか 200 を返すようにすることではありません。

影響します。ただし、まずよくある誤解を解いておく必要があります。

ですから、次のように単純化することはできません。

サイトのパフォーマンスで本当に注意すべきなのは、ユーザーが実際にサイトを閲覧するとき、ページが速く、安定していて、良い操作体験を提供しているかどうかです。

Google は Core Web Vitals を使って、サイトの利用体験のいくつかの重要な側面を測っています。

現在は主に次の 3 つで構成されています。

主要なコンテンツの読み込みにどれくらい時間がかかるかを測ります。

たとえば、企業サイトのヒーローセクションにある次のようなものです。

は、ページの LCP 要素になることがあります。

Google は、良好な体験の目安として LCP を 2.5 秒以内にすることを推奨しています。

ユーザーが操作してから、ページがどれだけ早く見た目で反応するかを測る指標です。

たとえば：

大量の JavaScript 処理がブラウザをふさいでいると、ページの読み込みが終わっていても、操作するともたつきや遅延を感じることがあります。

Google は、良好な INP の目安を 200ms 以内としています。

ページ読み込み中の見た目の安定性を測る指標です。

たとえば、ユーザーがボタンを押そうとした瞬間に画像が読み込まれ、画面全体が下に押し下げられる。

これがレイアウトシフトです。

Google は、良好な CLS の目安を 0.1 以下としています。

つまり Core Web Vitals は、次のようにシンプルに捉えられます。

PageSpeed Insights はとても便利ですが、企業がもっとも陥りやすい間違いは、Lighthouse の Performance Score を SEO の KPI にしてしまうことです。

たとえば、現在 92 点のサイトが

100 点を目指して

次のようなことを始めます。

結局、多くのコストをかけたのに、実際のユーザー体験やビジネスの成果ははっきり改善しません。

より妥当な優先順位は、実際の使い勝手と Core Web Vitals に影響している問題を先に解決することです。

テストツールで満点を取ることではありません。

これも PageSpeed Insights を使うときに大切な考え方です。

サイトのパフォーマンスデータは、大きく次の 2 つに分けられます。

PageSpeed Insights / Lighthouse は開発者がパフォーマンスの問題を見つける助けになりますが、実際のユーザーには次のような違いがあります。

そのため、サイトに十分なデータがある場合は、Core Web Vitals の実ユーザーデータ（Field Data）が大いに参考になります。

自社のパソコンで一度テストして Performance 95 が出たからといって、

すべてのユーザーが快適にサイトを使えていると判断すべきではありません。

企業サイトでは大きなヒーロー画像がよく使われます。

そしてヒーロー画像は LCP 要素になりやすいものです。

その画像が次のような状態だと：

LCP に直接影響するおそれがあります。

そのため、私たちのプラットフォームでは現在、トップページ最初のヒーロー画像の読み込み優先度を上げ、ほかの画像は遅延読み込み（Lazy Loading）のままにして、すべての画像が最初に一斉にダウンロードされないようにしています。また Next.js Image Optimizer を使い、WebP / AVIF、レスポンシブ画像、サイズ情報も提供しています。

この背景にある原則は、「すべての画像を Priority にする」ことではありません。

そうではなく、

CLS のよくある原因は次のとおりです。

たとえば画像の width / height をあらかじめ指定しておけば、

ブラウザは先にスペースを確保できます。

現在のプラットフォームの画像処理でもサイズ情報を提供し、画像の読み込み後にレイアウトシフトが起きる可能性を下げています。

つまり、サイトのパフォーマンス問題の多くは、サイト完成後に「高速化ツール」を入れてから解決し始めるものではありません。

サイトの構成やコンポーネント設計の段階から考えておくべきものです。

現代の企業サイトには、次のようなものがつい追加されがちです。

スクリプトが 1 つ増えるごとに、ブラウザが処理すべき作業も増える可能性があります。

そのため、テクニカルSEO とパフォーマンス改善は画像が圧縮されているかどうかだけを見ていては不十分です。

サイトが実際にどれだけの JavaScript を読み込んでいるか、そしてそれが本当に必要かも確認する必要があります。

ここは INP で特に注意すべきところでもあります。

より正確に理解すると、こうなります。

Google は Core Web Vitals をランキングシステムに使っていますが、同時に良好な Core Web Vitals がページの上位表示を保証するわけではないと明言しています。

Google 検索のランキングは、ほかにも多くのシグナルを考慮しているためです。

たとえば：

2 つの記事を比べた場合：

このとき、B のほうが必ず上位になるとは言えません。

ですから企業は、テクニカルSEO を「サイトが速いほど → SEO も必ず良くなる」ものにしてはいけません。

より妥当なのは、サイトは良好な Page Experience を提供すべきだが、検索戦略の核心は依然としてコンテンツの関連性と品質にあるという考え方です。

企業が「サイト全体で PageSpeed 100 点」を目指す必要はありません。

より妥当な進め方は次のとおりです。

このほうが、企業にとって本当の費用対効果に合っています。

SEO ツールのスコアのために、際限なく開発工数を注ぎ込むよりも。

React、Next.js、Vue などの JavaScript 技術を使うこと自体は、サイトの SEO が劣ることを意味しません。

本当に確認すべきなのは、

そのため JavaScript SEO の核心となる問いは、「サイトで JavaScript を使っているか？」ではありません。

「どの重要なコンテンツが JavaScript に依存していて、検索エンジンはそれを確実に取得できるか？」です。

従来型のサイトでは、検索エンジンがページをリクエストすると、通常サーバーはメインコンテンツを含んだ HTML をそのまま返します。

たとえば：

Googlebot は HTML を取得した時点で、メインコンテンツをそのまま確認できます。

しかし、一部の Client-side Rendering のサイトでは、最初に返される HTML が次のものだけのことがあります。

そのあと、

JavaScript をダウンロード → JavaScript を実行 → データを取得 → DOM を構築

してから、ようやく本当のコンテンツが表示されます。

Google は JavaScript を処理できますが、これによりレンダリング

という、考慮すべき工程が 1 つ増えます。

SEO の観点から、まずは 3 つの方式をシンプルに理解しておきましょう。

サーバーはまず基本的なページの骨組みを提供します。

そのあとブラウザが JavaScript を実行して、メインコンテンツを生成します。

流れはおおよそ次のようになります。

HTML Shell → JavaScript → API / Data → Content

SEO 上重要なコンテンツが完全に CSR に依存している場合は、検索エンジンが正しくレンダリングできるかを特に確認する必要があります。

ユーザーや検索エンジンがページをリクエストしたとき、サーバーが先にメインコンテンツを含む HTML を生成します。

そのため、最初のレスポンスにすでに次のものが含まれることがあります。

そのあと JavaScript がサイトのインタラクションを引き継ぎます。

ページの HTML は、ビルドなどの生成段階であらかじめ作られます。

検索エンジンやユーザーがサイトを訪れると、作成済みのページコンテンツをそのまま受け取れます。

そう単純には判断できません。

本当に重要なのは、最終的なサイトで Google が重要なコンテンツを正しく取得できるかどうかです。

Google は JavaScript をレンダリングできるため、CSR ≠ SEO ができないわけではありません。

同じように、SSR ≠ SEO が自動的に良くなるわけでもありません。

SSR のサイトでも、

といった状態なら、同じように SEO の問題が起こります。

つまりレンダリング戦略は、テクニカルSEO の基礎条件の 1 つであって、

検索順位を上げるテクニックではありません。

検索で価値のある公開ページでは、特に次の要素を確認すべきです。

これらを検索エンジンが確実に取得できるかどうかです。

一方、次のような純粋なインタラクション機能は：

通常、SEO のためにすべてを Server Rendering にする必要はありません。

これが、現代のサイトで Server + Client のハイブリッド構成 がよく採用される理由でもあります。

現在、TimTech のプラットフォームは Next.js App Router を使っています。

公開ページのメインコンテンツは主に Server Component で処理しています。たとえば：

そして：

などのインタラクション機能は、Client Component に任せています。

現在の実装を棚卸しした結果、JavaScript を無効にしても主要なテキストコンテンツは HTML に残っています。

この背景にある原則は、「JavaScript は少ないほど良い」ということではありません。

JavaScript には本当にインタラクションが必要なことを任せ、重要な検索コンテンツを必要もないのに Client-side Rendering に完全に依存させないということです。

JavaScript のサイトでもう一つよくある問題は、画面上ではクリックできそうに見えても、検索エンジンには通常のリンクとして見えていない場合があることです。

たとえば重要なナビゲーションが JavaScript の onclick イベントだけで、

実際に解析できる href がないと、検索エンジンがページを見つける方法に影響するおそれがあります。

そのため、重要な Internal Links では、やはり通常のリンクを用意するのが妥当です。

現代のフレームワークは独自の Routing Component を使えますが、最終的には検索エンジンが理解できるリンクを出力すべきです。

現在のプラットフォームでは、メインナビゲーション、フッター、記事やコンテンツのリンクに Next.js の <Link> または <a href> を使っており、JavaScript のイベントだけで遷移させてはいません。

SPA や Client-side Navigation では、別の種類の問題が起きることもあります。

ユーザーがクリックしたとき、サイトは従来のようなページ全体の再読み込みをせず、JavaScript でルートを切り替え → コンテンツを更新します。

これ自体は問題ありません。

ただし、URL ごとに次の要素が正しいことは確認する必要があります。

画面の内容は変わったのに、検索エンジンから見たページ情報が正しく変わっていないという状態ではいけません。

そのため JavaScript SEO では、「Google にテキストが見えているか？」だけを確認するのでは足りません。

インデックス対象の各 URL が、本当に完全で正しい 1 つのページを表しているかも確認する必要があります。

企業が自らサイトのフレームワークを研究する必要は必ずしもありません。

より実際的なのは、Google が実際に何を取得したかを確認することです。

たとえば Google Search Console の URL Inspection で、ページのインデックス状況やクロール状況を確認できます。

開発側では、さらに次の点を確認できます。

これは、単に「うちのサイトは Next.js か？」と聞くよりもはるかに意味があります。

Structured Data（構造化データ）とは、ページの内容を標準化された形式で記述する方法で、検索エンジンがこのページの情報が何を表しているかを理解しやすくするものです。

たとえばページに TimTech という文字があるとします。

検索エンジンはテキストからそれを理解できますが、Structured Data を使えば、サイト側からこれは Organization ですとより明確に伝えられます。

同じように：

これらの Schema Type は、検索エンジンがページの内容やエンティティを理解する助けになります。

Structured Data の話をすると、たいてい次の 2 つの用語が出てきます。

たとえば記事には、次のような記述が含まれることがあります。

これは Google 向けに別の記事を書くことではなく、ページにもともと存在する情報を構造化された形で記述するものです。

最大の価値は、Google がページの内容をより明確に理解できるようにし、条件を満たすコンテンツが特定の検索結果の表示形式（Search Appearance）を使えるチャンスを得られることです。

たとえば Google は、さまざまな種類の Structured Data に対応した検索機能をサポートしています。

ただし、ここには非常に大切な考え方が 2 つあります。

Schema が完全に正しくても、検索結果に表示するかどうか、どう表示するかは Google が独自に判断します。

そのため、Structured Data を「追加すれば順位が上がる SEO テクニック」と考えるべきではありません。

これは Structured Data を実装するうえで、もっとも重要な原則の一つです。

たとえば商品ページに実際の価格が表示されていないなら、

Product Schema を完全に見せるためだけに、適当な値を生成すべきではありません。

なぜなら 0 円は

商品が無料であることを意味するからです。

お見積りはお問い合わせくださいという意味にはなりません。

私たちのプラットフォームにも、まさにこの実際のケースがあります。

商品に実際の価格がある場合、Product の Structured Data で対応する Offer を生成できます。

しかし商品が見積依頼モードで

実際の価格がない場合は、Schema を埋めるためだけに偽の Offer を生成することはしません。

この原則は、「Schema は埋めれば埋めるほど良い」ということよりも重要です。

もう一つの重要な原則は、ユーザーに実際には見えない内容や、ページに存在しない内容を Structured Data に記述しないことです。

たとえばページに次のものがないのに：

より良い検索表示を得たいというだけで JSON-LD にこれらの情報を加えるのは、妥当なやり方ではありません。

Structured Data の役割はページの内容を記述することであって、

検索エンジンにしか見えない別のコンテンツを作り出すことではありません。

どのサイトでも、すべての Schema を実装する必要はありません。

実際のページ内容に合わせて決めるべきです。

現在、私たちのプラットフォームはページの種類に応じて次のものに対応しています。

そのため、妥当なやり方はすべてのページにあらゆる Schema を詰め込むことではありません。

ページが何であるかに応じて、それに対応する Structured Data を提供することです。

企業サイトに 300 本の記事 + 500 点の商品があるとして、

コンテンツ編集者に公開のたびに JSON-LD を手で書いてもらうのは、長期的に維持するのは明らかに難しいでしょう。

より妥当なのは次の流れです。

CMS Content

↓

ページの種類

↓

システムが対応する Structured Data を生成

たとえば記事を公開する時点で、システムはすでに次の情報を把握しています。

これらの既存データを使って、Article の Structured Data を生成できます。

現在のプラットフォームもこの方式をとっており、ページのデータと CMS のコンテンツから対応する JSON-LD を自動生成しています。

これにより、画面の内容は更新したのに、Structured Data の修正を忘れるというリスクを減らせます。

これは前述の Canonical と同じ原則です。

正式な URL が https://example.com/zh-TW/product-a なのに、

Structured Data では https://example.com/product-a を使っていて、

しかも後者がリダイレクトされるとします。

最終的には理解されるかもしれませんが、サイトがわざわざこうした不一致を生む必要はありません。

そのため、より良いやり方は次のとおりです。

これらすべてで、できるかぎり最終的な正式公開 URL を使います。

現在のプラットフォームもこの原則に従っています。

FAQPage は、かつて非常に人気のあった SEO 向けの Structured Data です。

しかし企業は、「FAQ Schema で検索結果の表示面積を増やせる」からといって、

FAQ を大量に作るべきではありません。

Google はすでに FAQ Rich Results の表示範囲を制限しており、現在は主に条件を満たす著名な政府機関や健康関連のサイトが対象です。

そのため、企業の記事でも本当に役立つ FAQ を作ることは引き続き可能です。

ただし、FAQ Schema を、一般的な企業サイトが必ず FAQ Rich Result を得られる方法だと考えてはいけません。

ここからも改めてわかるのは、Structured Data の価値はまず内容を正しく記述することにあり、SERP での見栄えを追うことではないということです。

Structured Data を実装したら、Google の Rich Results Test を使って

Google がサポートする Structured Data に次の問題がないかを確認できます。

また、Search Console でも Structured Data / Search Appearance に関する一部のレポートを確認できます。

ただし、テストに合格しても、それは技術的な形式が関連要件を満たしていることを意味するだけです。

Google が必ず Rich Result を表示するという意味ではありません。

Google Search Console は、キーワード、表示回数、クリック数、順位を確認するためだけのものではありません。

テクニカルSEO にとって、より重要な使い道の一つは次のことです。

サイトのコードが「正しく設定されているように見える」からといって、Google の実際の処理結果が期待どおりになるとは限らないからです。

そのため、テクニカルSEO のチェックはサイトの管理画面を見るだけでは足りず、Search Console に戻って Google が実際に見ている結果も確認する必要があります。

まずは Indexing → Pages を確認しましょう。

ここでは Google が把握しているサイトのページと、次のようなさまざまな状態を確認できます。

など。

ただし Not indexed を見ても、すぐに「サイトの SEO に問題がある」と考えないでください。

そもそもインデックスされるべきでないページもあるからです。

たとえば：

本当に確認すべきなのは、

重要なページが Google 検索に表示されていないとわかったら、URL Inspection（URL 検査）で特定の URL を確認できます。

たとえば：https://example.com/technical-seo

次のことを確認できます。

これはテクニカルSEO にとって特に重要です。

たとえばサイトでは Canonical → URL A と設定しているのに、

Search Console では Google-selected Canonical → URL B と表示される場合、

なぜ Google は B を主要なバージョンと判断したのか？をさらに調べる価値があります。

Indexing → Sitemaps でサイトマップを送信できます。たとえば：https://example.com/sitemap.xml

そして、Google が正しく読み込めているかを確認します。

サイトマップに問題がある場合は、さらに次の点を確認できます。

ただし、Sitemap Success ≠ すべての URL がインデックス済みであることは覚えておきましょう。

Sitemap レポートと Page Indexing レポートは、あわせて確認すべきです。

Search Console には Core Web Vitals レポートもあります。

企業はこれで、サイトに次のような URL があるかを確認できます。

そして、

などの Core Web Vitals 指標で、実際の使い勝手を判断します。

ここで非常に大切なのは、Search Console の Core Web Vitals は実際のユーザーデータを使っており、1 回の Lighthouse テストの結果ではないという点です。

そのため、PageSpeed Insights の Lab Test では良く見えるのに、Search Console ではまだ多くの Poor URLs が表示されている場合は、実際のユーザーが直面している問題をさらに調べる価値があります。

Search Console では、Google がサイトの HTTPS の状態をどう判断しているかも確認できます。

通常の企業サイトでは、主要な正式ページを HTTPS で提供するようにすべきです。

サイトが http://example.com と https://example.com の両方で存在する場合は、

一貫した正式バージョンとリダイレクトも設定すべきです。

現在のプラットフォームでは、Custom Domain の TLS / SSL は Vercel が処理しており、HTTP も HTTPS にリダイレクトされます。

つまり実装面で対応していることと、Search Console でGoogle が実際に見ているサイトの状態 から改めて検証することは別のことです。

サイトで Google がサポートする Structured Data を使っている場合、Search Console に関連するレポートが表示されることがあります。

次のような問題の発見に役立ちます。

ただし、ここでも Rich Result が表示されない ことを、そのまま Structured Data の実装ミスと判断しないでください。

Structured Data が正しいということは、ページが関連する技術条件の一つを満たしていることを意味するだけで、検索結果に表示するかどうか、どう表示するかは最終的に Google が決めます。

テクニカルSEO の監査は、赤い表示を見る → すべて直すという流れになりがちです。

しかし、それはもっとも効率的なやり方ではありません。

たとえば：

サイトに 404 が 500 件 あると、多く見えます。

しかし、それがすべて次のようなものなら：

優先度はそれほど高くないかもしれません。

逆に、重要なサービスページが 1 つだけ noindex になっている場合、

件数は 1 件でも、ビジネスへの影響は非常に大きい可能性があります。

そのため、テクニカルSEO の優先度は次の観点で判断すべきです。

単にどのレポートのエラー数がもっとも多いかで決めるのではありません。

企業が毎日すべてのレポートを確認する必要はありません。

まずは次の順番で進めるとよいでしょう。

このほうが、目的もなく Search Console のすべてのレポートを見るよりずっと効率的です。

サイトリニューアルは、テクニカルSEO で特に問題が起きやすい段階です。

リニューアルは通常、「サイトのデザインを新しくする」だけではないからです。

同時に次のものも変わる可能性があります。

これらをまとめて対応しないと、新しいサイトは問題なく公開されたのに、これまで積み上げてきた検索流入が減り始めるということが起こりえます。

そのため、既存の SEO 流入があるサイトをリニューアルするときは、テクニカルSEO を正式な Migration 作業として扱うべきで、公開後に後から対応するものではありません。

これはサイトリニューアルでもっともよくある問題の一つです。

たとえば旧サイトには /blog/seo-guide があり、

新サイトでは /resources/seo-guide に変わったとします。

古い URL をそのまま消してしまうと 旧 URL → 404

となり、古い URL を指していた次のものが：

すべて無効になります。

新しいページが古いページの代わりであるなら、旧 URL → Permanent Redirect → 新 URL を設定すべきです。

さらに、リダイレクトは最終的な URL へ直接向けるのが望ましく、A → B → C

のような不要な Redirect Chain は避けましょう。

リニューアルの際、大量の古い URL を手早く処理するために、すべての旧 URL → Homepage としてしまうチームもあります。

これは良い Migration Strategy ではありません。

たとえば：/products/machine-a

この製品がすでになく、新サイトにも対応するコンテンツがないなら、トップページにリダイレクトしても、次の問いに本当には答えていません。

「この古いページは今どこに移ったのか？」

より妥当なのは次の対応です。

リダイレクトは、コンテンツ同士の本当の新旧の対応関係を作るためのものです。

単にすべての 404 を消すためのものではありません。

リニューアルでは、画面に見えるコンテンツだけを移してしまいがちです。

そして元のページの次の要素を忘れてしまいます。

たとえば旧サイトでは、サービスページごとに異なる SEO Title をすでに設定していたとします。

新しいサイトの公開後、それがすべて 会社名｜公式サイト になってしまった。

これはデザインの問題ではなく、SEO Metadata の Migration が完了していないということです。

そのため、リニューアルを公開する前に、旧サイトの重要な SEO データを棚卸しし、新しいサイトに正しく移行されているかを確認すべきです。

サイト構成が変わったら、Canonical も改めて確認する必要があります。

よくある間違いは次のとおりです。

特に、Staging のドメインが本番サイトに持ち込まれることは、

サイトの Migration で確認する価値の高い項目です。

公開後は Canonical → 正式なドメイン + 最終的な正式 URL になっているかを確認しましょう。

ページが正常に開けるかどうかだけを確認するのではありません。

開発中は、テストサイトが Google にインデックスされないよう noindex

やその他のクロール／インデックスの制限を使うことがあります。

それ自体はまったく妥当です。

本当に危険なのは、公開後に外し忘れることです。

その結果、サイトは一見こう見えます。

しかし重要なページは、依然として検索エンジンにインデックスしないでと伝えています。

そのため、公開時のチェックリストには必ず robots.txt、robots meta、実際のインデックス設定の再確認を入れるべきです。

リニューアル後は、サイトマップが新しい本番サイトの状態を反映しているべきです。

たとえば、次のものを含め続けるべきではありません。

同時に、新しい

もサイトマップに正しく含まれている必要があります。

サイトマップが CMS によって本番のコンテンツから自動生成されるなら、こうした問題は通常コントロールしやすくなります。

現在、私たちのプラットフォームでは、正式に公開されインデックスが許可されたコンテンツをもとにサイトマップを動的に生成し、正式な Canonical URL を使っています。

すでに Old URL → Redirect → New URL を設定していても、

サイト内のリンクを長期的にリダイレクトに頼るべきではありません。

たとえば記事 A のリンクがまだ /old-seo-guide のままで、

最終的には /seo-guide にリダイレクトされるとしても、

よりきれいなやり方は、やはり Internal Link を直接 /seo-guide に更新することです。

そのため、サイトの Migration が終わったら、改めてサイトをクロールして次の点を確認すべきです。

サイト自身の Internal Linking が、すでに新しい正式 URL を使っていることを確認しましょう。

リニューアルでコンテンツを 1 つも削除せず、URL も変えないことがあります。

それでも、サイトのナビゲーション構造が大きく変わることがあります。

たとえば、もともとは トップページ → サービスページ だったのが、

リニューアル後は トップページ → ソリューション → 業界 → カテゴリ → サービスページ になる。

重要なページが、ユーザーにも検索エンジンにも見つけにくくなります。

そのため Migration は URL Mapping だけではありません。

サイトの情報設計と Internal Linking も改めて確認する必要があります。

特に、もともと検索流入とビジネス上の価値があった重要なページが、リニューアル後に突然見つけにくい孤立したコンテンツになってはいけません。

サイトが WordPress から

React / Next.js / Headless CMS に変わる、

あるいはその逆の場合もあります。

このとき、見た目やコンテンツがまったく同じでも、検索エンジンがコンテンツを取得する方法は変わっているかもしれません。

次の点を改めて確認する必要があります。

つまり、

**「Google は以前の旧サイトをインデックスできていた」からといって、「新しいサイトも内容は同じだから、絶対に問題ない」**とは言えません。

Rendering Architecture が変わったあとも、改めて検証が必要です。

国際向けサイトのリニューアルでは、特に注意が必要です。

たとえば旧サイトが

から、次のように変わったとします。

このとき、リダイレクトのほかに次の要素も関わってきます。

ページを移すだけで、各言語版どうしの関係を作り直さなければ、International SEO の問題が起こる可能性があります。

既存サイトにすでに SEO の流入があるなら、私たちは次の進め方をおすすめしません。

新しいサイトを作り終える → 公開 → 404 に気づく → それからリダイレクトを追加し始める。

より妥当なのは、公開前に次の内容を整理しておくことです。

Old URL

↓

New URL

↓

Action

たとえば：

この URL Mapping は、Migration の中心となる拠り所になります。

現在のプラットフォームの実装では、システムですでに次のことに対応しています。

そのため、システムがコンテンツの Slug 変更を自動で処理するだけでなく、サイト管理者は Redirect Manager でほかの URL の転送も管理できます。

これはサイトリニューアルで特に重要です。

たとえば企業が旧サイトから新しいプラットフォームへ移行するとき、まず 旧サイトの URL → 新サイトの URL という URL Mapping を作り、そのうえで残すべき旧 URL に恒久的なリダイレクトを設定できます。

ただし、プラットフォームに Redirect Manager があっても、既存サイトに大量の検索流入が蓄積しているなら、そのまま移行することはおすすめしません。

より完全な流れは、やはり 旧サイトの URL Audit → URL Mapping → リダイレクト設定 → 新サイト公開 → Search Console / クロールでの検証 であるべきです。

Redirect Manager が解決するのは「リダイレクトをどう実行するか」であって、どの旧 URL をどの新 URL へ向けるべきかは、実際のコンテンツと SEO 上の価値をもとに判断する必要があるからです。

テクニカルSEO の問題は、多くの場合「SEO をまったくやっていない」ことではなく、次のようなことです。

サイトにはすでに Sitemap、Canonical、robots.txt、Structured Data などの設定があるのに、それぞれの設定が互いに矛盾している。

そのため、テクニカルSEO の監査のポイントは、単に「この機能があるかどうか」を確認することではありません。

「正しく設定されていて、サイトのほかの SEO シグナルと一貫しているか」を確認することです。

以下は、企業サイトでもっともよく見られ、優先して確認する価値の高いテクニカルSEO の問題です。

もっとも深刻なケースの一つが、本番サイトの重要なコンテンツが robots.txt でブロックされていることです。

たとえば：

このルールが本番サイトにあると、検索エンジンにサイト全体をクロールしないよう求めているのと同じです。

もう一つは、あまり目立たないケースです。

ところが、/products/ がちょうど企業にとってもっとも重要な商品コンテンツだったりします。

そのため、サイトの公開、リニューアル、robots.txt の調整を行ったあとは、

重要なページが引き続きクロールを許可されているかを必ず確認し直すべきです。

もう一つよくある問題は、重要なページが普通に閲覧できるのに、noindex が設定されていることです。

この問題は、ユーザーにはまったく気づかれないことがほとんどです。

サイトは：

しかし検索エンジンは、このページをインデックスに追加しないで という指示を受け取っています。

特に Staging から本番環境へ移すときは、テスト中に使っていた noindex が正しく外されているかに注意しましょう。

サイトマップは主に、サイトが検索エンジンに処理してほしい正式な URL を提供するものです。

そのため、サイトマップに次のような URL が大量に含まれているなら：

サイトマップがサイトのほかのテクニカルSEO シグナルと一貫していないことを意味します。

たとえば Sitemap：これは重要な URL です

なのに Meta Robots：インデックスしないで

というのは、不要な矛盾です。

Canonical は、自動化された設定のミスによって大量のページに影響しやすいものです。

よくある問題は次のとおりです。

そのため、HTML に「canonical タグがある」ことを確認するだけでは足りません。

それが実際にどこを指しているかも確認する必要があります。

サイトで次のものを変更したあと：

旧 URL にすでに次のものが蓄積していた場合：

それがそのまま 404 になってしまうと、不要な検索資産の損失につながる可能性があります。

新旧のコンテンツに明確な対応関係があるなら、適切な恒久的リダイレクトを設定すべきです。

そのため、URL は 自由に書き換えてよいテキスト項目として扱うべきではありません。

URL そのものが、サイトが長い時間をかけて蓄積してきた検索資産の一つです。

リダイレクトがあるからといって、適切に処理されているとは限りません。

たとえば：

/page-a

↓

/page-b

↓

/page-c

↓

/page-d

これは、URL の変更を何度も重ねるうちに、新しいリダイレクトが古いルールの後ろに次々とつなげられてきたことを意味します。

よりきれいな形は、できるだけ /page-a → /page-d にすることです。

そのため URL Migration を行うときは、リダイレクトが最終的に正式な URL を直接指しているかも定期的に確認すべきです。

サイト内に大量の Internal Link → 404 があると、

ユーザー体験を損なうだけでなく、サイト自身のコンテンツ構造が一貫性を失っていることも意味します。

よくある原因は次のとおりです。

そのため、旧 URL にすでにリダイレクトを設定していても、サイト自身の Internal Link を少しずつ 最終的な正式 URL に更新していくことをおすすめします。

サイト内部の構造を、長期的にリダイレクトで補修し続けるのは避けましょう。

Soft 404 は見落とされやすい問題です。

たとえば、ページには 「このコンテンツは見つかりません。」 と表示されているのに、

サーバーは実際には 200 OK を返している。

これでは検索エンジンに矛盾したシグナルが届く可能性があります。画面はコンテンツが存在しないと言っているのに、HTTP はページが正常だと言っているのです。

そのため 404 の対応は、見栄えのよい 404 ページをデザインすることだけではありません。

より重要なのは、サーバーが正しい HTTP Status Code を返すことです。

JavaScript サイトによくあるテクニカルSEO の問題は、「React を使っていること」ではありません。

重要なコンテンツが Client-side JavaScript に完全に依存しており、検索エンジンが確実に取得できないことです。

たとえば：

が初期コンテンツに含まれておらず、さらに Rendering でエラーが起きている場合です。

そのため JavaScript サイトでは、検索エンジンが最終的にどんなコンテンツを取得したかを実際に確認すべきです。

ブラウザの画面だけを見て、「自分には見えているから、Google にも見えているはず」と判断するのではありません。

Structured Data でもっともよくある間違いの一つが、Schema のためにページに存在しないデータを作り出すことです。

たとえば：

こうした問題は、「Schema Validation Passed」かどうかで正しさを判断することはできません。

技術的な形式が正しいこと ≠ データの内容が正しいことだからです。

Structured Data は最終的に、ユーザーが実際に目にする内容を反映していなければなりません。

テクニカルSEO のもう一つのよくある誤解は、エンジニアリングのリソースをすべて PageSpeed Insights に注ぎ込むことです。

サイトのパフォーマンスは重要です。

しかしテクニカルSEO には、ほかにも次のものが含まれます。

重要なサービスページが noindex になっていれば、

たとえ PageSpeed が 100 点でも、

本当の SEO の問題は解決していません。

そのためテクニカルSEO の優先順位は、実際の検索への影響にもとづいて

決めるべきで、どのツールのスコアがいちばん目につくかで決めるべきではありません。

最後に、企業サイトでもっとも影響範囲が大きい問題の一つが、サイトのリニューアルでデザインとコンテンツだけを扱い、SEO Migration を扱わないことです。

その結果、次のようなことが起こり得ます。

そのため、サイトにもともと検索流入があるなら：

サイトを公開したあとに流入の減少に気づいてから、対処を始めるものではありません。

企業は、問題を見つけたらすべてを同時に対処する必要はありません。

より合理的なのは、まずこう問うことです。「この問題は、重要なページの Crawling や Indexing を妨げているか？」

そうであれば：→ 最優先。

次に確認します。大量の重要な URL、Canonical、リダイレクト、またはサイト構成のエラーを引き起こしているか？

そうであれば：→ 優先して対処。

最後が、改善幅が比較的小さく、検索エンジンによるサイトの処理を直接妨げていない最適化項目です。

そのため、重要なサービスページ 1 つに誤って noindex が設定されていることは、

何の価値もない古い 404 URL 500 件 よりも優先して対処すべき場合があります。

テクニカルSEO は多くの技術的な細部にわたりますが、企業が毎日すべての項目を確認する必要はありません。

より現実的なのは、サイトの公開時、リニューアル時、SEO 監査時、または検索のインデックスに異常を見つけたときに、決まったチェックリストに沿って確認する方法です。

以下は、企業サイトのテクニカルSEO の基本的なチェックリストとして使えます。

核心となる問いは、実は 2 つだけです。

「Google は重要なコンテンツを取得できるか？」、そして「本当に重要なコンテンツはインデックスが許可されているか？」

CMS を使う企業サイトでは、Sitemap は XML を手作業で編集するのではなく、実際のコンテンツの状態にもとづいてシステムが自動で維持するのが理想です。

本当の目標は**「すべてのページに canonical タグがあること」ではなく、「サイト全体で正式な URL の判断が一貫していること」**です。

現在、私たちのプラットフォームでは Slug 変更時の自動リダイレクトに加えて、汎用の Redirect Manager も備えており、ほかの旧 URL → 新 URL の転送も管理できます。

Internal Linking はコンテンツ SEO であるだけでなく、検索エンジンがサイトの情報設計を理解するための重要な土台でもあります。

ポイントは、

**「サイトで JavaScript を使ってはいけない」ではなく、「重要な検索向けコンテンツを、検索エンジンが確実に取得できなければならない」**ということです。

Schema は多ければよいわけではありません。

数よりも正確さが大切です。

パフォーマンス最適化の核心は、やはり「実際のユーザー体験を改善すること」です。

既存サイトのリニューアルであれば、さらに次の点を確認します。

最後に、特に注意しておきたいことがあります。

テクニカルSEO のチェックリストは確認のためのツールであって、SEO の採点表ではありません。

サイトによって、

はすべて異なります。

20 ページほどの企業ブランドサイトと、数万点の商品を扱う EC プラットフォームとでは、対処すべきテクニカルSEO の深さが当然異なります。

そのため、より合理的な原則は変わりません。

テクニカルSEO の目的は、SEO 監査ツールの表示をすべて緑にすることではありません。

サイトそのものを検索での成長の障害にしないことです。

テクニカルSEO は多くの技術用語が関わっているように見えます。

しかし、これらの項目は最終的にすべて同じことに行き着きます。

企業が SEO に取り組むとき、コンテンツは依然としてとても重要な核です。

次のことを理解する必要があります。

テクニカルSEO は、こうした取り組みに取って代わるものではありません。

テクニカルSEO が扱うのは別の問題です。企業がよいコンテンツを作ったあと、サイトそのものに、そのコンテンツが正常に検索に参加できるだけの正しい技術的な土台があるかどうか。

そのためテクニカルSEO は、サイトとともに継続的に維持していく必要がある技術的な土台です。

この土台がしっかり築かれていれば、企業は記事を 1 本追加するたびに、Canonical、Sitemap、Structured Data などの基盤部分の問題を改めて処理する必要がなくなります。

そして、本当に重要なことにより多くの時間を使えます。検索ニーズを理解し、専門的なコンテンツを作り、ユーザー体験を改善し、サイトの検索価値を継続的に積み上げていくことです。