本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第8弾として、SEO（検索エンジン最適化）について解説する記事です。
レンダリング方式・URL設計・メタデータ戦略はアーキテクチャ選定段階で決まってしまい、後から付け足せない領域です。本記事ではレンダリング方式とSEOの関係・メタタグ・OG画像・構造化データ・sitemap・URL設計・i18n・Core Web Vitalsまで、初期設計で組み込むための指針を示します。フロント固有のセキュリティ（XSS / CSP）は前回の認証認可記事に委ねます。
この記事の結論
- SEOは初期設計でほぼ決まる（後付けは高くつく）
- SSG / SSRを基本にする
- メタタグ・sitemap・構造化データはフレームワーク標準で自動化する
- Lighthouse / Search Consoleで週次計測し、数値で追う
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもSEO設計とは何か
SEO設計とは、ざっくり言えば「検索エンジンにサイトの内容を正しく理解してもらい、検索結果で上位に表示されるための技術的な土台作り」です。
看板の出し方を想像してください。どれだけ美味しい料理を出す店でも、看板が読めない・地図に載っていない・入口が分からない状態では客は来ません。SEO設計はWebサイトの「看板・地図・入口」を検索エンジン向けに整える作業です。
なぜSEO設計が重要なのか
もしSEOを後回しにしたらどうなるか。開発完了後に「SEOが弱い」と気づいても、レンダリング方式の変更は設計からやり直しで、後付けのコストは10倍になります。URL設計・canonical設定・構造化データ・OGタグは、コンテンツの良し悪しに関係なく技術的な設計ミスで検索順位が下がる要因です。
Googleのアルゴリズムは年々ユーザー体験の良いサイトを優遇する方向へ進化しており、SEOはコンテンツ・パフォーマンス・アクセシビリティ・構造化データの総合戦です。広告に頼らない集客の根幹になります。
SEOとレンダリングの関係
| 方式 | SEO | 理由 |
|---|---|---|
| SSR / SSG | ◎ | 検索エンジンがHTMLを直接読める |
| CSR | △ | JS実行が必要・解釈はされるが遅延 |
| Dynamic Rendering | ◯ | Bot向けだけSSRする折衷案 |
CSRでもGoogleクローラーはJS実行後のHTMLを読むので技術的には認識されますが、実行タイミングが数日〜数週間遅れるため、鮮度が求められるサイトでは大きな不利です。SEOを本気で狙うならSSG / SSRが原則です。
メタタグ・OG・構造化データ
<head> 内のメタタグは検索エンジンにページ情報を伝える最初の一歩です。
<head>
<title>記事タイトル | サイト名</title>
<meta name="description" content="ページの要約120字以内">
<link rel="canonical" href="https://example.com/post/1">
</head>原則は3つ、titleとdescriptionはページ毎にユニーク（全ページ同じは致命的）、canonicalで重複URLを一本化（末尾スラッシュあり/なし問題）、robotsでindex / noindexを明示です。Next.jsの metadata API、Astroの <SEO> コンポーネントなど、FW標準の仕組みで一貫管理します。
Open Graph / Twitter CardsはSNSシェア時のプレビューを制御するメタタグで、OGの良し悪しでクリック率が数倍動きます。画像サイズは1200×630pxが鉄板で、毎回手動で作るのは非現実的なので「タイトルからOG画像を自動生成」する仕組み（Vercel OG Image等）を組み込みます。
構造化データ（JSON-LD）は、検索結果にリッチスニペット（星評価・FAQ・パンくず）を出すためのメタ情報です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトル",
"datePublished": "2026-04-18"
}
</script>Article / FAQ / BreadcrumbList / Organizationあたりが最低ラインで、検索結果で視覚的に目立ちCTRが一段上がります。sitemap.xml / robots.txtはフレームワークの自動生成プラグインに任せます。手書きは初回しか合わず、すぐ実態と乖離して破綻します。
URL設計とi18n
URLは人間が読んで意味が分かるのが原則です。
✅ /blog/how-to-use-astro
❌ /blog.php?id=42意味のある単語を含め、小文字・ハイフン区切り、階層は2〜3段まで。一度公開すると変更が難しいため初期設計に時間をかける価値があり、やむを得ず変える時は301リダイレクトで旧URLから誘導します。
多言語サイトでは、サブディレクトリ（/en/）・サブドメイン（en.example.com）・別ドメインのいずれかで言語を分け、hreflangで対応関係を明示します。これがないとGoogleに「同じ内容の重複」と誤認されてランキングが落ちます。本プロジェクト（senkohome.com）はサブドメイン方式（en.senkohome.com）を採用しています。
どう運用するか ― SEOの数値Gate
※ 2026年4月時点の業界標準値です。
SEOは測定可能です。数値で追うことで曖昧な議論が消えます。
| 指標 | 推奨値 | 確認ツール |
|---|---|---|
| Lighthouse Performance / SEO / Accessibility | 各90点以上 | Lighthouse |
| LCP / INP / CLS | < 2.5秒 / < 200ms / < 0.1 | PageSpeed Insights・Search Console |
| title / descriptionのユニーク率 | 100% | Search Console |
| 構造化データエラー | 0件 | Rich Results Test |
| 画像alt属性 | 100%設定 | axe-core |
Core Web Vitalsは検索順位に直接影響します。改善策は画像最適化（WebP/AVIF）・フォントpreload・JSバンドル削減・画像サイズ属性指定で、1回やって終わりではなく週次で継続監視する運用が前提です。
3つのシナリオで考える
個人開発・スタートアップの場合
AstroやNext.jsのSSGに乗るだけで、技術的SEOの8割は片付いてしまいます。メタタグ・OGP・sitemap・構造化データはフレームワークの標準機能で自動生成されますので、人間はコンテンツの独自性に集中するべきです。ただ、Search Consoleの登録だけは初日にやっておいてください。
中小SaaSの場合
集客ページ（LP・ブログ・機能紹介）をISRやSSGで配信して、Core Web Vitalsを週次で監視する運用を確立する段階です。SEOが売上に直結するビジネスであれば、Lighthouse CIをパイプラインに組み込んで、スコアが劣化したらデプロイを止める仕組みまで入れる価値は十分にあると思います。
大企業の場合
複数ドメイン・多言語・大量ページの構造管理が本題になってきます。hreflangやcanonical、サイト移転時のリダイレクト設計を誤ると数年分の検索資産を失ってしまうため、SEO専任者とエンジニアの共同レビュー体制を作っておくべきでしょう。
AI判断軸 ― 技術的SEOはAI、独自性は人間
メタデータ生成はAIが正確にこなせる
title・description・OGタグ・JSON-LD構造化データの生成はAIの得意領域です。Next.jsの metadata APIやAstroのSEOコンポーネントに沿った形式で書かせれば、構文エラーなく正確なメタデータが出力されます。sitemapやリダイレクト設定の自動化コードも同様です。
AI量産記事とSEOの関係
2024年以降、GoogleはAI生成コンテンツを「作成方法」ではなく「品質」で評価する方針を明確にしています。しかし一次情報や独自体験に基づかないAI量産記事は、他の量産記事と差別化できずランキングが上がりません。E-E-A-T（専門性・経験・権威性・信頼性）が強いサイトは、AI量産コンテンツが溢れる時代にこそ相対的な価値が上がります。AIは構造・メタデータ・技術的SEOの最適化に使い、コンテンツの独自性は人間が担保する分業が有効です。
やってはいけないこと
検索流入激減の原因を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 全ページ同じtitle / description | 重複判定でインデックスが大幅減する → 記事ごとに固有にする |
| canonicalタグ未設定 | URL表記ゆれでSEO評価が分散する → 全ページに設定する |
| CSRのみでSEO必須サイトを構築 | クローラーのJS実行が数週間遅延する → SSG / SSRにする |
| 301リダイレクトなしでURL変更 | SEO評価がリセットされる → 必ず301で旧URLを誘導する |
| hreflang未設定の多言語展開 | 重複コンテンツ扱いになる → 言語ごとの対応を明示する |
| Core Web Vitalsの計測を運用に入れない | 悪化に気づかず順位がじわじわ下がる → 週次計測を組み込む |
筆者メモ ― 「titleが全ページ同じ」だけで沈んだ事例
ある小規模メディアでは、200記事以上の <title> がサイト名のみで統一されていた、という話が語られています。Search Consoleで確認するとインデックスされているのは10数記事だけ。記事ごとの識別情報がなく、Googleから重複ページ扱いされていたわけです。各記事に固有のtitle / descriptionを入れ直し、canonicalを整えたところ、数ヶ月で検索流入が10倍以上に伸びたと言います。
逆に言えば、それまで基礎の基礎を落としているだけで9割以上の流入機会を失っていたということです。SEOは「見えないところで評価されている」領域で、手を抜いた分だけ静かに損失が積み上がります。テクニックより固有メタデータと計測が9割です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- レンダリング方式（SEO観点）
- メタデータ標準（title / description / OGの管理方法）
- sitemap / robotsの生成方法（自動プラグイン）
- 構造化データの採用範囲
- URL設計規約
- i18n方式（サブディレクトリ / サブドメイン）
- Core Web Vitalsの計測ループ（週次Lighthouse）
この記事に関連する記事
まとめ
本記事はSEOについて、レンダリング方式・メタタグ・OG画像自動生成・構造化データ・sitemap・URL設計・i18n・Core Web Vitalsまで含めて解説しました。如何だったでしょうか。
SEOは初期設計でほぼ決まる。SSG/SSRを基本に、フレームワーク標準で機械的な部分を自動化し、独自性は人間が担保する。これが2026年のフロントSEO設計の現実解です。
次回からは新しいカテゴリ（データアーキテクチャ）の解説に入ります。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（44/95）