テクニカルSEOとは？コンテンツSEOとの違いと施策、点検の手順を解説

テクニカルSEOとは、検索エンジンがサイトのページを見つけ、内容を読み取り、検索結果に出せる状態に整える、技術面のSEOのことです。

どれほど良い記事もGoogleに届かなければ評価されないため、テクニカルSEOは中身より先に整える土台です。本記事では、コンテンツSEOとの違いと施策、点検の手順を解説します。

なお、自社のサイトに技術的な問題が隠れていないか気になる方は、カルテットコミュニケーションズのSEOコンサルティングの無料相談もご活用ください。

Search Consoleの状況とサイトの作りを拝見し、直す順番と、社内で対応できる範囲を一緒に整理します。

テクニカルSEOとは？コンテンツSEOとの違い

テクニカルSEOは言葉だけを聞くと難しく感じますが、やっていることは、Googleがページを扱う流れの中で、つまずく所をなくすことです。

まずは定義と、よく比べられるコンテンツSEOとの違いを押さえます。

定義①｜Googleに「届く・読める・登録できる」状態をつくる施策

Googleは、クローラーと呼ばれるプログラムでページを取りに来て、内容を解析し、インデックスと呼ばれるデータベースに保存してから検索結果に表示します。

テクニカルSEOは、この流れのどこかでページが止まらないように、サーバーやHTML、サイトの構造を整える取り組みです。

SEO（検索エンジン最適化）では、検索エンジンにコンテンツを理解させることで、ユーザーが検索エンジンからサイトを見つけてアクセスすべきかどうかを判断できるようにします。

引用元：Google検索セントラル「Google 公式 SEO スターター ガイド」

Googleの説明にある「検索エンジンにコンテンツを理解させる」ための技術的な下準備が、テクニカルSEOにあたります。

テクニカルSEOは、ページがGoogleに届き、読まれ、登録されるまでの通り道を整える施策と考えましょう。

違い②｜コンテンツSEOは中身を、テクニカルSEOは届け方を直す

コンテンツSEOは、検索する人の疑問に答える記事やページをつくり、検索結果で選ばれることをめざす施策です。

一方のテクニカルSEOは、ページの中身ではなく、URLの設計やサーバーの応答、HTMLの書き方など、中身の届け方を直します。

比べる点	テクニカルSEO	コンテンツSEO
直す対象	サーバー・HTML・サイト構造	記事やページの中身
主な作業	URL設計・転送・タグの設定	検索語句の選定・構成・執筆
主な担当	エンジニア・制作会社	編集者・ライター
効く範囲	テンプレート単位でサイト全体	1ページずつ
確かめる場所	登録の状況・クロールの状況	検索語句・クリック数

役割は違いますが、どちらか片方だけでは成果につながりにくく、両方がそろって初めて力を発揮します。

「どちらが大事か」と聞かれることもありますが、順番で考えると、ページが届く状態をつくるテクニカルSEOが先です。

記事を書く前に、その記事がGoogleに届く状態になっているかを確かめましょう。

関係③｜内部対策のうち、サイトの仕組みで決まる部分を受け持つ

SEOは、自社のサイトの中で行う内部対策と、ほかのサイトからの評価に関わる外部対策に分けて説明されることがあります。

テクニカルSEOは内部対策の一部で、ページごとの書き方よりも、サイト全体の仕組みに関わる部分を受け持ちます。

たとえば、URLのルール、リダイレクト、robots.txt、canonical、表示の速さ、JavaScriptの扱いなどです。

これらはCMSのテンプレートやサーバーの設定で決まることが多く、記事を書く人だけでは気づきにくいのが特徴です。

テクニカルSEOは、内部対策の中でも「仕組みで決まる部分」を見る施策として切り分けましょう。

メリット④｜一度の修正がサイト全体に効く

テクニカルSEOのいちばんのメリットは、テンプレートや設定を1か所直すと、同じ仕組みで作られたすべてのページに効くことです。

記事の書き直しは1ページずつの改善ですが、たとえば全ページに付いていた誤ったnoindexを外せば、まとめて検索結果に出せる状態に戻せます。

もう1つのメリットは、問題がSearch Consoleのエラーや数字として見えるため、原因と効果を追いかけやすいことです。

さらに、表示の速さやスマホでの読みやすさを整えると、検索から来た人だけでなく、広告やSNSから来た人の使いやすさも上がります。

テクニカルSEOは、少ない作業でサイト全体の取りこぼしを減らせる施策です。

テクニカルSEOの施策①｜クロールの通り道を整える

Googleは、すでに知っているページのリンクをたどったり、サイトマップを読んだりして、新しいページを見つけます。

最初の段階で通り道が整っていないと、ページを公開しても見つけてもらえず、その先の評価まで進みません。

施策①｜URLは意味の分かる単語で、ルールをそろえる

URLは、読者にも検索エンジンにも、ページの中身を伝える手がかりになります。

GoogleはできるだけシンプルなURL構造をすすめており、単語の区切りにはアンダースコアではなくハイフンを使うよう案内しています。

また、Googleは/APPLEと/appleを別々のURLとして扱うため、大文字と小文字が混ざらないようにルールを決めておきます。

並べ替えや絞り込み、参照元を示すパラメータでURLが増えすぎると、同じ内容のURLが大量にでき、クロールの無駄につながります。

URLは、意味の分かる単語・ハイフン・小文字でそろえ、不要なパラメータを減らしましょう。

施策②｜内部リンクとパンくずリストで階層を示す

サイトの中のページは、トップページ・カテゴリ・個別のページのように、内容のまとまりで階層に分けると整理しやすくなります。

上の階層から下の階層へリンクでたどれるようにしておくと、Googleも読者も、どこに何があるかを把握しやすくなります。

パンくずリストは、「ホーム＞コラム＞記事」のように現在地を示すリンクで、階層をページの上でも見せられます。

どこからもリンクされていないページは見つかりにくいため、サイトマップに載せるだけでなく、関連するページからもリンクを張ります。

大事なページほど、上の階層や関連するページからリンクでたどれるようにしましょう。

施策③｜XMLサイトマップで大事なページを伝える

XMLサイトマップは、サイトの中で検索エンジンに知ってほしいURLの一覧を書いたファイルです。

WordPressなど多くのCMSでは自動で作られるため、まずはどこにあるか、検索結果に出したくないページまで載っていないかを確かめます。

載せるのを、正規のURLで200を返すページだけにしておくと、Googleに伝わる情報が食い違いにくくなります。

作ったサイトマップは、Search Consoleの「サイトマップ」から送信し、読み込まれたかを確かめます。

サイトマップには、検索結果に出したい正規のURLだけを載せて送信しましょう。

施策④｜robots.txtは「読ませない場所」だけに使う

robots.txtは、クローラーに対して、サイトの中で読み込んでほしくない場所を伝えるファイルです。

管理画面や、内容が同じで並べ方だけが違うページなど、クロールさせても意味のない場所を止めるのに使います。

注意したいのは、robots.txtは「検索結果に出さない」ための仕組みではないことです。

読み込みを止めたページでも、ほかのページからリンクされていればURLが登録されることがあるため、検索結果から外したいページにはnoindexを使います。

robots.txtはクロールを止める道具、noindexは検索結果から外す道具として使い分けましょう。

テクニカルSEOの施策②｜インデックス登録の状態を整える

ページが見つかっても、サーバーの応答やタグの指定しだいで、インデックスに登録されないことがあります。

この段階では、ページの本当の状態と、Googleに伝えている情報が合っているかを確かめます。

施策⑤｜ページの状態に合ったステータスコードを返す

HTTPステータスコードは、ページを読み込んだときにサーバーが返す3桁の数字で、Googleはこの数字を見てページの扱いを決めます。

公開中のページは200、移転したページは301、削除して代わりがないページは404か410と、ページの状態に合った数字を返すのが基本です。

サーバーが不安定で5xxのエラーが続くと、Googleはクロールを控えるようになります。

5xx および 429 のサーバーエラーは、Google のクローラに対して一時的にクロールのペースを落とすように促します。Google 検索の場合、すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます。

引用元：Google のクロール インフラストラクチャ「HTTP ステータス コードが Google のクローラーに及ぼす影響」

また、存在しないページなのに200を返し、「ページが見つかりません」と表示するだけの作りは、Search Consoleでソフト404として扱われます。

削除したページを残すか消すかの判断は、古くなった記事、削除する？残す？も参考にしてください。

ページの状態と、サーバーが返すステータスコードを一致させましょう。

施策⑥｜noindexは検索結果に出さないページだけに付ける

noindexは、ページをインデックスに登録しないようGoogleに伝える指定で、HTMLのmetaタグかHTTPヘッダーで書きます。

お問い合わせの完了ページや社内向けのページなど、検索結果に出しても読者の役に立たないページに付けます。

CMSのテーマやプラグインの設定で、カテゴリやタグのページにまとめてnoindexが付くこともあるため、意図した設定かを確かめます。

noindexとnofollowの違いや使い分けは、noindexとnofollowで詳しく解説しています。

noindexは、検索結果に出さないと決めたページにだけ付けましょう。

施策⑦｜重複するURLはcanonicalで正規のURLを示す

同じ内容のページが、wwwの有無や末尾のスラッシュ、パラメータの違いなどで、複数のURLから見られることがあります。

Googleは重複したページの中から代表となる正規ページを選びますが、望むURLをこちらから示しておくと、評価を1つのURLにまとめやすくなります。

類似ページや重複ページについてシグナルを統合するため。これにより、検索エンジンが、個々の URL について得られたシグナル（その URL へのリンクなど）を、優先すべき 1 つの URL に統合できるようになります。

引用元：Google検索セントラル「rel=”canonical” などを利用して正規ページを指定する方法」

正規のURLは各ページのheadにrel=”canonical”で書き、サイト内のリンクやサイトマップも同じURLにそろえます。

Googleは、正規化の方法ごとに違うURLを指定しないよう案内しているため、canonical・内部リンク・サイトマップの食い違いをなくします。

canonical・内部リンク・サイトマップは、同じ正規のURLを指すようにそろえましょう。

施策⑧｜URLを変えたら301リダイレクトでつなぐ

サイトのリニューアルや記事の統合でURLが変わるときは、古いURLから新しいURLへ301リダイレクトを設定します。

Googleは301を、転送先のURLを処理すべきという強いシグナルとして扱うため、古いURLの評価を新しいURLへ引き継ぎやすくなります。

転送は内容が対応するページへ1対1で行い、何度も転送を重ねるチェーンや、行き先が元に戻るループを作らないようにします。

Googleのクローラーがたどる転送の回数には上限があり、表示までの時間も延びるため、移転を重ねたら最終の行き先へ直接つなぎ直します。

URLを変えるときは、古いURLごとに内容が対応するページへ301でつなぎましょう。

テクニカルSEOの施策③｜ページを正しく読ませる

Googleはページを取得したあと、JavaScriptを実行して、人が見る画面に近い形を組み立ててから内容を読み取ります。

Google は、JavaScript ベースのウェブアプリを 3 つの主要なフェーズで処理します。

引用元：Google検索セントラル「JavaScript SEO の基本を理解する」

3つのフェーズとは、クロール、レンダリング、インデックス登録のことで、レンダリングで組み立てた内容が登録の対象になります。

施策⑨｜JavaScriptに頼りすぎず、リンクと本文をHTMLに出す

レンダリングとは、取得したHTMLとJavaScriptを処理して、ページの画面を組み立てることです。

Googleはレンダリングしたあとの内容を読みますが、レンダリングには順番待ちがあり、すぐに処理されるとは限りません。

Googleがリンクとしてたどれるのは、href属性の付いたaタグです。クリックしたときの処理だけで画面を切り替えるメニューは、リンクとして見つけてもらえません。

Google が noindex タグを検出した場合は、レンダリングと JavaScript の実行がスキップされる可能性があります。

引用元：Google検索セントラル「JavaScript SEO の基本を理解する」

そのため、登録したいページの元のHTMLにnoindexを入れておき、JavaScriptで後から外すような作りは避けます。

Search ConsoleのURL検査で「公開 URL をテスト」を行うと、Googleから見たHTMLや画面を確かめられます。

リンクはhref付きのaタグで書き、本文がGoogleから見えるかをURL検査で確かめましょう。

施策⑩｜スマホでもパソコンと同じ内容を見せる

Googleは、インデックス登録とランキングに、スマートフォン用のクローラーで取得したモバイル版のページを使っています。

これをモバイルファーストインデックスと呼び、スマホ版で本文や画像、構造化データを省いていると、Googleが受け取る情報もそのぶん減ります。

Googleは、実装と維持がもっとも簡単な方法として、同じURL・同じHTMLで画面の幅に合わせて表示を変えるレスポンシブデザインをすすめています。

スマホでは長い説明をアコーディオンやタブに収めるなど、表示の仕方を工夫しても、内容そのものはパソコンとそろえます。

スマホ版でも、パソコン版と同じ本文・画像・構造化データを見せましょう。

施策⑪｜構造化データでページの情報を補う

構造化データは、ページの情報を決まった書式で書き、検索エンジンが内容を理解しやすくする仕組みです。

パンくずリストや商品、イベントなど、Googleが対応している種類では、検索結果での見え方が変わることがあります。

書いた構造化データは、Googleのリッチリザルトテストで読み取れるかを確かめ、ページに表示している内容と食い違わないようにします。

構造化データは、ページの中身を補う情報なので、ページに書いていないことを構造化データだけに書くのは避けます。

構造化データは、対応している種類のページから加え、テストで確かめましょう。

施策⑫｜表示の速さとHTTPSを整える

Googleは、ランキングの仕組みを、優れたページエクスペリエンスを提供するコンテンツを高く評価するように設計しているとしています。

表示の速さ、操作への反応、表示のずれにくさはCore Web Vitalsという指標で測り、Search Consoleの「ウェブに関する主な指標」レポートで確かめられます。

あわせて、サイト全体をHTTPSで配信し、本文を覆う煩わしいインタースティシャル（全面表示の広告やポップアップ）を避けることも、使いやすさにつながります。

画像の圧縮や、使っていないプラグインの整理など、テンプレート全体に効く改善から手を付けると、効率よく進められます。

表示の速さは、Core Web Vitalsのレポートで改善が必要なページから直しましょう。

テクニカルSEOの点検手順｜Search Consoleで不具合を見つける

テクニカルSEOは、思いついた施策を順に試すより、Search Consoleで問題が出ている所を見つけて直すほうが、少ない手間で効果につながります。

Google Search Consoleについてで基本の使い方を押さえたうえで、次の4つの手順で点検します。

手順①｜大事なページが登録されているかをURL検査で確かめる

最初に、トップページ、サービスや商品のページ、問い合わせにつながるページなど、検索から来てほしいページを書き出します。

それぞれのURLをSearch ConsoleのURL検査に入れ、インデックスに登録されているか、Googleが選んだ正規のURLが意図どおりかを確かめます。

Search Consoleのヘルプでも、ページ数が500未満のサイトなら、詳しいレポートより先に主要なページの登録を確かめる進め方が案内されています。

まずは検索から来てほしいページを決め、URL検査で登録の状況を確かめましょう。

手順②｜「ページのインデックス登録」で未登録の理由を仕分ける

「ページのインデックス登録」レポートでは、登録されなかったページが、理由ごとにまとめて表示されます。

未登録のすべてが問題というわけではなく、noindexを付けたページや、重複として正規のURLにまとめられたページは、意図どおりなら対応は要りません。

サーバーエラー、リダイレクトのエラー、ソフト404は技術的な不具合なので、テンプレートやサーバーの設定から原因を探します。

「クロール済み – インデックス未登録」は、技術的な設定に問題が見当たらなければ、ページの中身が読者の役に立つかを見直す合図です。

未登録の理由を「直す」「意図どおりか確かめる」「中身を見直す」に仕分けましょう。

手順③｜サイトの規模に合わせてクロールの状況を見る

ページ数が多いサイトでは、設定の中にある「クロールの統計情報」レポートで、Googleのリクエストの数やサーバーの応答に問題がないかを確かめられます。

Search Consoleのヘルプでは、このレポートは上級者向けで、ページ数が1,000未満のサイトなら使う必要はないとされています。

小さなサイトであれば、クロールの細かな数字よりも、手順①と②で大事なページの登録を確かめることを優先します。

クロールの統計情報は、ページ数の多いサイトでサーバーの応答を見るときに使いましょう。

手順④｜直したら修正の検証をリクエストして結果を追う

レポートで見つけた問題を直したら、その理由の詳細画面から、Googleに修正の検証をリクエストできます。

検証の進み具合は画面で追えるため、直した日と内容を記録しておき、該当するページが減っていくかを確かめます。

テンプレートを変えたときやプラグインを更新したときも、同じ手順で大事なページを確かめ直すと、事故に早く気づけます。

直したら検証をリクエストし、テンプレートを変えるたびに大事なページを確かめ直しましょう。

テクニカルSEOでよくある失敗と防ぎ方

テクニカルSEOの失敗は、1つの設定がサイト全体に効くぶん、影響も大きくなりがちです。

特に、サイトの公開やリニューアル、テーマの変更のタイミングで起きやすいため、よくある例を押さえておきます。

失敗①｜テスト環境のnoindexやrobots.txtを残したまま公開する

制作中のサイトは、検索結果に出ないように、noindexやrobots.txtの「Disallow: /」で止めておくことがよくあります。

その設定を外し忘れて本番に公開すると、サイト全体が検索結果に出ない、またはクロールされない状態が続きます。

WordPressでは、表示設定の「検索エンジンがサイトをインデックスしないようにする」にチェックが入ったままになっている例もあります。

公開の手順に、noindexとrobots.txtを本番用に切り替える確認を入れましょう。

失敗②｜テンプレートのcanonicalが全ページでトップを指す

テーマやプラグインの設定を誤ると、すべてのページのcanonicalがトップページのURLになってしまうことがあります。

この状態では、各ページがトップページの重複として扱われ、個別のページが検索結果に出にくくなります。

「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」が急に増えたら、canonicalの設定を疑います。

canonicalは、各ページが自分自身のURLを指しているかをソースで確かめましょう。

失敗③｜リニューアルで古いURLをトップにまとめて転送する

リニューアルでURLが大きく変わったとき、手間を省いて、古いURLをすべてトップページへ転送してしまう例があります。

読者は探していたページにたどり着けず、Googleにとっても古いページと新しいページの対応が分からなくなります。

古いURLと新しいURLの対応表を作り、内容が近いページへ1対1で301リダイレクトを設定します。

対応するページがない古いURLは、無理に転送せず404か410を返すほうが、ページの状態を正しく伝えられます。

リニューアルの前に、古いURLと新しいURLの対応表を作りましょう。

失敗④｜JavaScriptだけでメニューや本文を出す

見た目を重視したサイトでは、メニューのリンクや本文を、JavaScriptで後から読み込む作りになっていることがあります。

人がブラウザで見ると問題がなくても、Googleがリンクをたどれなかったり、本文の読み取りが遅れたりすることがあります。

Googleは、サーバー側でHTMLを組み立ててから返すサーバーサイドレンダリングも、有効な方法として挙げています。

メニューと本文が、JavaScriptを実行しなくてもHTMLに出ているかを確かめましょう。

テクニカルSEOのよくある質問

最後に、テクニカルSEOについてよくいただく質問に答えます。

質問①｜小さなサイトでもテクニカルSEOは要る？

要りますが、やるべきことは絞れます。

ページ数が少ないサイトでは、大事なページが登録されているか、noindexやrobots.txtの設定が誤っていないか、スマホで同じ内容が読めるかを確かめれば、多くの問題は防げます。

細かな速度の改善や、大規模なサイト向けの施策は、これらが整ってから考えれば十分です。

小さなサイトは、登録の状況・noindexとrobots.txt・スマホ表示の3点から確かめましょう。

質問②｜クロールバジェットは気にしたほうがよい？

クロールバジェットとは、Googleが1つのサイトのクロールにかけられる時間とリソースの割り当てのことです。

Googleのガイドは、主に、重複のないページが100万以上ある大規模なサイトや、1万以上のページが毎日のように更新されるサイトを対象にしています。

ページ数がそこまで多くないサイトでは、クロールバジェットよりも、URLの増えすぎやサーバーエラーなど、ほかの問題を先に確かめます。

クロールバジェットは、ページ数がとても多いサイトになってから考えましょう。

質問③｜WordPressなら対策しなくて大丈夫？

WordPressは、XMLサイトマップの作成やcanonicalの出力など、テクニカルSEOの基本の多くを自動で行います。

ただし、テーマやプラグインの組み合わせで、noindexやcanonicalの設定が重なったり、表示が重くなったりすることがあります。

プラグインを入れたり更新したりしたあとは、URL検査で、大事なページの登録の状況とGoogleから見た画面を確かめます。

WordPressでも、プラグインの設定が重なっていないかを定期的に確かめましょう。

質問④｜自社でやる？会社に頼む？

URL検査やレポートの確認、サイトマップの送信、noindexの付け外しなど、管理画面から行える作業は自社でも進められます。

一方で、サーバーの設定やテンプレートの改修、リニューアルに伴うURLの移行は、誤ると多くのページに影響するため、専門の会社と進めるほうが安全です。

依頼するときは、作業の前後でSearch Consoleの数字を比べ、何を変えたかを共有してもらえる体制かを確かめます。

サイトの仕組みに関わる対応に不安がある場合は、カルテットコミュニケーションズのSEOコンサルティングでもご相談を受け付けています。

管理画面でできる確認は自社で、サイトの仕組みを変える作業は専門の会社と進めましょう。

質問⑤｜リスティング広告を出しているサイトで気をつけることは？

弊社はリスティング広告の運用を本業としていますが、広告を出しているサイトには、テクニカルSEOで見落としやすい点が2つあります。

1つ目は、広告のクリックで付くgclidなどのパラメータ付きのURLです。Googleも、パラメータ付きのURLへのシグナルを正規のURLにまとめる例を挙げており、canonicalを正しく出しておけば重複を防げます。

2つ目は、robots.txtの書き方です。Google広告がページを確かめるAdsBotは、すべてのクローラーに向けた「User-agent: *」の指定に従いません。

たとえば、AdsBot は広告パブリッシャーの許可に基づき、グローバル robots.txt ユーザー エージェント（*）を無視します。

引用元：Google のクロール インフラストラクチャ「Google の特殊なケース用のクローラー」

反対に、AdsBotを名前で指定して止めると、Google広告がページの広告品質を確かめる機能に影響するため、広告のランディングページでは止めないのが基本です。

広告とSEOの役割分担は、リスティング広告とSEOを併用するメリットでも解説しています。

広告を出しているサイトは、パラメータ付きURLのcanonicalと、AdsBotの扱いを確かめましょう。

まとめ｜テクニカルSEOは、記事を書く前に整える土台

テクニカルSEOは一度整えれば終わりではなく、サイトの公開やリニューアル、プラグインの更新のたびに確かめ直す施策です。

まずは、検索から来てほしいページをURL検査にかけ、登録の状況とGoogleが選んだ正規のURLを確かめるところから始めてみてください。

テクニカルSEOの点検や、コンテンツとあわせた進め方に迷う方は、カルテットコミュニケーションズのSEOコンサルティングの無料相談もご活用ください。

Search Consoleのデータと広告の運用データもあわせて拝見し、直す順番と体制を一緒に決めます。