🏗️ 第 02

サイト構築 & 技術的SEO

技術的な土台 ―― 正しく作る(0 → 1)

📖 14 分で読めます 🕑 更新日 2026-06-22

サイト構築とテクニカル SEO のレイヤーが解決する問題はひとつだけです。検索エンジンがあなたのページをスムーズに発見・クロール・理解・インデックスできるようにすることです。このレイヤーはキーワードリサーチの後、コンテンツ制作の前に位置します。どれだけ精緻にリサーチしても、どれだけ良い文章を書いても、クローラーがページを読めなかったり、URL がぐちゃぐちゃだったり、ページが 3 秒間も真っ白なままだったりすれば、ランキングは論外です。

朗報があります。ここは コードを書く人が最も優位に立てるレイヤー です。専門用語を取り払ってみれば、ほとんどの「テクニカル SEO の問題」は、設定ファイル・HTTP ヘッダー・HTML タグ・パフォーマンスチューニングにすぎません。あなたが毎日やっていることそのものです。クローラーは、JavaScript を待つ忍耐がなく、時間予算も厳しい、ちょっとせっかちな HTTP クライアントだと思ってください。あなたの仕事は、クリーンで速く、ラベル付けの行き届いた HTML を返すことです。このページでは、コピペできるコードとともにそのすべてのパーツを順に解説します。

ドメインとホスティング

コンテンツの 1 バイトが意味を持つよりも前に、リクエストは名前解決され、接続され、素早く応答される必要があります。それがドメインとホスティングです。

ドメインの選び方。 短く、覚えやすく、トピックに合致していそうな ものを選びましょう。いくつか実践的なルールがあります。

  • 真新しいドメインに「ドメイン年齢」ボーナスはありませんが、有害なバックリンク履歴も背負っていません。まっさらな状態でまったく問題ありません。
  • ハイフンを詰め込んだ完全一致キーワードドメイン（best-cheap-seo-tools-2026.com）は避けましょう。スパムっぽく見え、上位に上がるどころか順位は下がります。
  • 正規のホストをひとつ 決めて貫きましょう。www あり/なしを一度決めたら、もう片方は永久にリダイレクトします。

HTTPS は譲れません。 これは（軽いとはいえ）確認済みのランキングシグナルであり、最近のブラウザは素の HTTP を「保護されていない通信」と表示します。301 リダイレクトと HSTS ヘッダーであらゆる箇所に強制し、ブラウザが二度と HTTP を試さないようにしましょう。

# nginx: redirect all HTTP to HTTPS, then enforce HSTS
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name www.example.com;
  return 301 https://example.com$request_uri;   # consolidate www -> apex
}
server {
  listen 443 ssl;
  server_name example.com;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
  # ... your site ...
}

上記のパターンは、4 つのアドレス（http://、https://、www あり、www なし）をひとつの正規オリジンに集約します。これを省くと、検索エンジンはそれらを最大 4 つの別サイトとみなし、同じ権威性（オーソリティ）を分散させてしまう恐れがあります。

TTFB とサーバー応答時間。 Time To First Byte は、リクエストを受けてからサーバーが最初の 1 バイトを送るまでの時間です。Google は遅い応答をクロール効率の問題として扱います。サーバーがもたつくと、1 回の訪問でクロールされるページ数が減ります。キャッシュ/静的レスポンスでは TTFB を 約 200ms 未満、動的なものでも約 600ms 未満を目指しましょう。

CDN。 Content Delivery Network はユーザーに物理的に近いサーバーにページをキャッシュし、グローバルなオーディエンスのレイテンシを大幅に削減し、トラフィックの急増も吸収します。静的サイトならこれはほぼ無料でほぼ魔法のようなものです。HTML、CSS、画像が、大陸の向こう側ではなく訪問者から数百キロメートルのエッジノードから配信されます。

🧑‍💻 開発者視点：curl で実際のレスポンスを確認しましょう。200、strict-transport-security の存在、そして意図しない x-robots-tag: noindex がないことを確かめます。

curl -sI https://example.com | grep -iE 'http/|strict-transport|x-robots'

サイトアーキテクチャ

アーキテクチャとは、URL とリンクの構成のことです。これが正しければ、権威性がスムーズに流れ、クローラーはすべてに到達できます。間違えると、重要なページがサブフォルダ 3 階層の奥で、どこからもリンクされない孤立した状態（オーファン）に置かれてしまいます。

クリーンでセマンティックな URL。 URL はパンくずリストのように読めるべきです。比較してみましょう。

Good:  example.com/seo/technical/canonical-tags
Bad:   example.com/index.php?p=482&cat=7&ref=nav

経験則：小文字、単語間はハイフン（アンダースコアやスペースではなく）、ファイル拡張子なし、正規パスにセッション ID やトラッキングのゴミを入れない、そして人間が実際にタイプしそうな単語を使うこと。URL は人間にもクローラーにも、そして SERP であなたのリンクをクリックするかどうか判断する人にも読まれます。説明的に保ちましょう。URL が検索結果でどう表示されるか見たいですか？ 当サイトの SERP プレビューツール を使ってください。

フラットな階層。 重要なページはすべて トップページから約 3 クリック以内 で到達できるようにしましょう。ツリーが浅いほど「リンクエクイティ」が深いページまで届き、クローラーも見つけやすくなります。到達に 7 クリックかかるページは、あなたがそのページを重要視していないことを（正しく）示してしまいます。

内部リンクとトピッククラスターモデル。 内部リンクには 2 つの役割があります。クローラーをサイト内に誘導することと、ページ間で権威性を受け渡すことです。最も効果的な構造は トピッククラスター です。

  • ひとつの ピラーページ が大きなトピックを広くカバーします（/seo/technical-seo）。
  • 複数の クラスターページ がそれぞれ 1 つのサブ論点を掘り下げます（/seo/technical-seo/robots-txt、/seo/technical-seo/sitemaps）。
  • 各クラスターページはピラーへ上向きにリンクし、ピラーは各クラスターへ下向きにリンクします。

これにより検索エンジンには「このサイトはテクニカル SEO の権威だ」と伝わります。「このサイトには robots.txt についてのページが 1 枚ある」だけではありません。click here ではなく、必ず 説明的なアンカーテキスト（robots.txt configuration）を使いましょう。アンカーテキストはリンク先ページのランキングシグナルになります。

💡 ヒント：サイトを 1 本の木としてイメージしてください。トップページが根、カテゴリーが枝、記事が葉です。クローラーは内部リンクをたどって木を登ります。内部リンクが 1 本も入ってこない孤立ページは、宙に浮いた葉のようなもので、いつまでもクロールされないかもしれません。

テクニカル SEO

ここがこのレイヤーの中核であり、あなたのホームグラウンドです。以下のすべては、ファイルか、タグか、ヘッダーのいずれかです。

robots.txt

サイトルート（example.com/robots.txt）に置くプレーンテキストファイルで、クローラーがどのパスをリクエストしてよいかを伝えます。重要なのは、これが制御するのは クロールであってインデックスではない という点です。robots.txt でブロックされたページも、他サイトからリンクされていれば（スニペットのない URL だけの状態で）検索結果に現れることがあります。何かを インデックスから外す には noindex が必要です。後述します。

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /*?sort=          # block faceted/sort parameter URLs

Sitemap: https://example.com/sitemap.xml

⚠️ 注意：noindex でインデックスから外したいページを、同時に Disallow してはいけません。クローラーがページを取得できなければ、noindex タグを 見る ことができず、ページはインデックスに居座り続けます。クロールをブロックする か、クロールを許可して noindex を付けるか、どちらか一方にしましょう。両方はダメです。

sitemap.xml

インデックスして ほしい URL を列挙した XML です。インデックスを保証するものではありませんが、Google にクリーンな在庫リストを手渡す手段です。大規模サイトや内部リンクの少ないページでは非常に有用です。正規かつインデックス可能で、ステータス 200 のページだけ を含めましょう（リダイレクト・noindex・重複はなし）。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/seo/technical-seo</loc>
    <lastmod>2026-06-22</lastmod>
  </url>
  <url>
    <loc>https://example.com/seo/technical-seo/robots-txt</loc>
    <lastmod>2026-06-20</lastmod>
  </url>
</urlset>

Google Search Console（Sitemaps セクション）で送信し、robots.txt から参照しましょう。これを手作業でメンテナンスしてはいけません。当サイトの robots.txt & サイトマップ生成ツール で両ファイルを生成しましょう。

canonical

同じコンテンツが複数の URL（トラッキングパラメーター、末尾スラッシュ、HTTP と HTTPS、印刷用ページ）で到達できる場合、canonical タグが「本物」を指定し、権威性が分散せず集約されるようにします。<head> に置き、優先するページでは 自己参照 にしましょう。

<!-- on https://example.com/shoes?color=red -->
<link rel="canonical" href="https://example.com/shoes" />

絶対 URL を使い、1 ページにつき canonical はひとつだけ、そして canonical 先の URL 自体が（リダイレクトや noindex ではなく）200 を返すことを確認しましょう。canonical は強い ヒント であって命令ではありません。シグナルの一貫性を保ち、たとえば robots.txt でブロックしたページを canonical 先に指定するようなことはやめましょう。

hreflang（多言語対応）

同じコンテンツを複数の言語や地域で提供している場合、hreflang はどのバージョンをどのユーザーに見せるかを Google に伝えます。誰もがつまずくルールはこれです。参照は双方向かつ完全でなければならない ——セット内の各ページは、自分自身を含むすべてのバージョンを列挙しなければなりません。フォールバック用に x-default を追加しましょう。

<!-- in <head> of every page in the language set -->
<link rel="alternate" hreflang="en"    href="https://example.com/en/build" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/build" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/build" />

英語ページが中国語ページを指しているのに、中国語ページが指し返していなければ、Google はクラスター全体を無視します。ISO 言語コード（en、zh-CN）を使い、代替ページ（alternate）に robots.txt や noindex を絶対に使わないでください。すべてクロール可能である必要があります。

Schema 構造化データ

構造化データは、ページが 何であるか（記事、レシピ、商品、FAQ）を記述する機械可読なメタデータです。Google はこれを使って リッチリザルト（星評価、FAQ アコーディオン、SERP 上のパンくず）を生成します。これらは順位が変わらなくてもクリック率を押し上げます。<script> タグ内で JSON-LD を使いましょう。Google 推奨の形式であり、マークアップとコンテンツを分離して保てます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A Developer's Guide to Technical SEO",
  "author": { "@type": "Person", "name": "Jane Dev" },
  "datePublished": "2026-06-22",
  "dateModified": "2026-06-22",
  "image": "https://example.com/img/technical-seo.png"
}
</script>

実際にページ上に表示されているコンテンツだけをマークアップしましょう（偽装すると手動ペナルティのリスクがあります）。そして Google のリッチリザルトテストで検証します。Article、Breadcrumb、FAQ、Organization の有効な JSON-LD は、当サイトの Schema 生成ツール で生成できます。

モバイルファーストインデックス

Google はデスクトップ版ではなく、ページの モバイル版 を使ってインデックスし、ランク付けします。実務上の帰結は次のとおりです。コンテンツ・見出し・構造化データを「デスクトップ専用」のパスに隠さないこと。モバイルページに同じ本文テキスト、同じ hreflang/canonical タグ、同じ Schema があることを確認すること。レスポンシブレイアウト（HTML ペイロードはひとつ、CSS 駆動のブレークポイント）が最も安全なパターンです。同期を保つべきバージョンがひとつしかないからです。

Core Web Vitals

実世界のユーザー体験を定量化し、ランキングに直接フィードされる 3 つの指標です。目標値は「良好」のしきい値です。

指標測るもの良好よくある対処
LCP（Largest Contentful Paint）最大要素が描画されるまでの時間≤ 2.5sヒーロー画像の最適化・プリロード、TTFB の高速化
INP（Interaction to Next Paint）ユーザー入力への応答性≤ 200ms長い JS タスクの分割、JavaScript の削減
CLS（Cumulative Layout Shift）視覚的安定性（ガタつかないこと）≤ 0.1画像に width/height を設定、広告/埋め込み枠を確保

CLS で最も効果が大きいのは、ブラウザが読み込み前にスペースを確保できるよう、メディアに寸法を指定することです。

<!-- browser reserves the box immediately; nothing jumps when the image arrives -->
<img src="/hero.webp" width="1200" height="630" alt="Technical SEO diagram" />

Lighthouse（ラボデータ）と Search Console の Core Web Vitals レポート（実ユーザーからの実フィールドデータ）で計測しましょう。Google が実際に使うのはフィールドデータなので、フィールドデータに対して最適化してください。

クロールバジェット、インデックス管理、重複コンテンツ

クロールバジェット とは、一定期間内に Google があなたのサイトから取得する URL の有限の数です。小規模サイトが上限に達することは稀ですが、大規模サイト（5 万 URL 以上、巨大な EC のファセット）は確実に達します。クローラーがゴミにバジェットを費やすと無駄になります。無限のパラメーター組み合わせ、ページネーションの行き止まり、リダイレクトチェーン、ソフト 404 などです。

重複コンテンツ はそのバジェットを薄め、ランキングを混乱させます。対処の道具立て：

  • 近重複（絞り込み/並べ替えされた商品リスト）を集約するには canonical を使う。

  • 公開しておく必要はあるがランクさせたくない薄いページ（サイト内検索結果、タグアーカイブ）には noindex を使う。

    <meta name="robots" content="noindex, follow" />

    または HTML 以外のファイルにはヘッダー版を使う。

    X-Robots-Tag: noindex

  • SEO 上の価値がまったくないセクション全体（/cart/、ファセットパラメーター URL）にクローラーがバジェットを浪費するのを止めるには robots.txt を使う。

  • リダイレクトチェーン（A → B → C）を単一ホップ（A → C）に修正する。ホップごとにバジェットを消費し、わずかに権威性が漏れます。

🧑‍💻 開発者視点：「あらゆる URL はクローラーがコストを払うリクエストだ」という観点で考えましょう。公開前に Screaming Frog のようなツールで自分のサイトをクロールし、リストを監査しましょう。たいてい数百のパラメーター URL、カレンダーページ、ページネーションされたアーカイブが、静かにバジェットを食べているのが見つかります。

スタックの選択

選ぶフレームワークや CMS によって、SEO がどこまで自動で処理されるか、どこまで手作業で配線するかが決まります。決め手は HTML がどうやってクローラーに届くか です。サーバーレンダリング/静的 HTML（最高）か、それとも最初のレスポンスが空の <div id="root"> シェルで、JavaScript が走った後にようやく中身が埋まるクライアントサイドレンダリング（危険——クローラーが遅れて描画する、あるいは完全には描画しない恐れがある）か。

スタックレンダリングSEO との相性備考
WordPressサーバーレンダリング高い（プラグインあり）Yoast / Rank Math が meta、サイトマップ、Schema を処理。パフォーマンスはキャッシュプラグイン頼み。
Webflowサーバーレンダリング/静的標準で高いtitle/canonical/hreflang フィールドを内蔵したビジュアルビルダー。カスタムロジックは限定的。
Next.jsSSR または SSG（あるいは CSR）設定すれば高いフルコントロールできるが、generateMetadata と動的サイトマップルートで SEO を自分で配線する。デフォルトの CSR は相性が悪い。
Astroデフォルトで静的（SSG）非常に高いデフォルトで JS をゼロ出力 → 高速な HTML、自然に Core Web Vitals が好成績。コンテンツ/ドキュメント/ブログに最適。当サイトは Astro で動いています。

⚠️ 注意：純粋なクライアントサイドレンダリングのシングルページアプリは、初回読み込みで空の HTML シェルを返します。Google は JavaScript を描画 できます が、遅く、信頼性が低く、他のクローラー（一部のソーシャルや AI ボット）はまったく描画しません。SEO が重要なら、最初のバイトにすでにコンテンツが含まれるよう SSG か SSR を選びましょう。

コンテンツ中心の SEO サイトをゼロから構築する開発者には、静的優先のジェネレーター（Astro、または SSG モードの Next.js）が最良のデフォルトを与えてくれます。速い TTFB、最初のレスポンスにクリーンな HTML、そして上で扱ったすべてのタグを簡単に制御できます。

まとめ

このレイヤーのマインドセットはこうです。クローラーにクリーンで速く、ラベル付けの行き届いた HTML を返し、決して推測させない。 あらゆる「テクニカル SEO の問題」は、ファイル・タグ・ヘッダー・ミリ秒に還元されます——それはまさに、あなたがすでに解き方を知っている種類の問題です。面倒なファイルを手書きせず、当サイトの robots/サイトマップ と Schema のツールで生成し、そのうえですべてを検証しましょう。

✅ チェックリスト

  • サイト全体で HTTPS を強制し、HSTS を追加し、すべてのドメイン亜種（http、www）をひとつの正規オリジンに 301 リダイレクトする
  • robots.txt と sitemap.xml を生成・送信し、正規でステータス 200 のページだけを含める
  • 重要なページすべてに自己参照の canonical タグを追加し、重複/パラメーター URL を解消する
  • 複数言語を提供しているなら、完全かつ双方向の hreflang タグ（と x-default）を設定する
  • Article、Breadcrumb、Organization の JSON-LD 構造化データを追加し、リッチリザルトテストを通過させる
  • Lighthouse を実行し、LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1 を確認する——Search Console のフィールドデータと突き合わせて検証する
  • URL リストを（例：Screaming Frog で）監査し、孤立ページ・リダイレクトチェーン・バジェットを浪費するパラメーター URL を洗い出す