SEOコーディングとは？ — コードの書き方が検索順位に直結する理由
SEOコーディングとは、検索エンジンがWebページのコンテンツを正確にクロール・インデックスできるようにHTMLを記述する技術です。多くのWeb制作者が「SEO対策＝キーワードを入れること」と誤解していますが、実際にはHTMLの構造そのものが検索エンジンの理解度に大きく影響します。
検索エンジンは「見た目」ではなくソースコードを読む
なぜコードの書き方がSEOに影響するのか。その理由は、Googleのクローラー（Googlebot）の情報処理プロセスにあります。Googlebotはページにアクセスするとき、人間のようにCSSでレンダリングされた「見た目」を評価するのではなく、HTMLのソースコードを構文解析して「文書構造」と「意味」を抽出します。
たとえば、<div class="title">と<h1>は、人間の目にはCSSで同じ見た目にできますが、検索エンジンにとっては意味がまったく異なります。<h1>は「このページの最も重要な見出しである」というセマンティック（意味的）情報を持ちますが、<div>にはそのような情報がありません。GoogleのSEOスターターガイドでも、HTMLの適切な使用がSEOの基本として強調されています。
さらに2026年現在では、SEOコーディングは検索エンジン向けだけでなく、LLMO（AI検索最適化）の観点でも重要になっています。ChatGPTやGeminiなどのAI検索がWebページの情報を取得する際も、HTMLの構造を解析して情報を抽出するため、セマンティックに正しいHTMLはAI検索での引用率向上にもつながるのです。
前提知識：現在のHTML標準は「HTML Living Standard」
コーディング規約の前提として押さえておきたいのが、HTML標準の変化です。かつての標準だった「HTML5」は2021年1月に廃止され、現在はWHATWGが策定するHTML Living Standardが唯一のHTML標準になっています。バージョン番号を持たず継続的に更新される仕様のため、「HTML5では正しかった書き方」が現在は非推奨になっているケースもあります。
実務上の影響が大きいのは、セクショニング要素（<article>や<section>）の扱いや、廃止された属性・要素の存在です。後述するW3CのチェックツールもHTML Living Standard基準で検証されるため、これから書くコードはこの最新仕様に沿わせるのが基本です。
自分のページのソースコードを確認する方法
SEOコーディングの改善は、まず現状のコードを見ることから始まります。特別なツールは不要で、ブラウザだけで確認できます。
- ソース表示：ページ上で右クリック→「ページのソースを表示」（またはURL欄に
view-source:https://example.com/）。サーバーが返した「素のHTML」を確認できます。 - デベロッパーツール：F12キー（Macは Cmd+Option+I）→「Elements」タブ。JavaScriptが実行された後の「レンダリング済みDOM」を確認できます。
重要なのは、この2つが一致しない場合があることです。JavaScriptで後からコンテンツを生成しているサイトでは、「ソース表示」では空っぽなのに「Elements」には本文がある、という状態になります。この差分が大きいサイトは、後述するJavaScript SEOの問題を抱えている可能性があります。
セマンティックHTMLの実践 — 検索エンジンが「意味」を理解するコード
セマンティックHTMLとは、HTMLタグが持つ「意味」を活用してWebページの構造を記述する手法です。<div>や<span>のような意味を持たないタグの代わりに、<header>、<nav>、<main>、<article>、<section>、<footer>などの意味的なタグを使うことで、検索エンジンに「ページのどこに何があるか」を正確に伝えることができます。
Before/After — div地獄からセマンティックHTMLへ
まず、多くのサイトで見られる「SEO的にNGなコード」と、それを改善した「セマンティックなコード」を比較しましょう。
❌ Before（div地獄 — SEO的にNG）：
<!-- NG例：すべてdivで構成されており、構造の意味が不明 -->
<div class="wrapper">
<div class="header">
<div class="logo">サイト名</div>
<div class="nav">
<div class="nav-item"><a href="/">ホーム</a></div>
<div class="nav-item"><a href="/about">会社概要</a></div>
</div>
</div>
<div class="content">
<div class="title">記事タイトル</div>
<div class="text">本文テキスト...</div>
</div>
<div class="footer">© 2026</div>
</div>✅ After（セマンティックHTML — SEO最適化済み）：
<!-- 改善例：セマンティックタグで構造を明確化 -->
<header>
<a href="/" aria-label="サイトトップへ">
<img src="/logo.webp" alt="サイト名ロゴ" width="180" height="40">
</a>
<nav aria-label="メインナビゲーション">
<ul>
<li><a href="/">ホーム</a></li>
<li><a href="/about">会社概要</a></li>
</ul>
</nav>
</header>
<main>
<article>
<h1>記事タイトル</h1>
<p>本文テキスト...</p>
</article>
</main>
<footer>
<p>© 2026</p>
</footer>この2つのコードは、CSSで同じ見た目にすることができます。しかし検索エンジンにとっては、まったく異なる情報を伝えています。Afterのコードでは、<header>で「ここがヘッダーエリアである」、<nav>で「これはナビゲーションである」、<main>で「これがページのメインコンテンツである」、<article>で「これが記事本文である」ということが明確に伝わります。
当サイトでは、サイト構築時にすべてのページをセマンティックHTMLで記述しました。特に<main>タグと<article>タグの適切な使用は、Googlebotがメインコンテンツを正確に特定するために重要です。これにより、クロール効率が向上し、インデックスの精度が高まります。
見出しタグ（h1〜h6）の階層ルール
見出しタグはSEOコーディングの中でも最も基本的かつ重要な要素です。検索エンジンは見出しタグの階層構造を解析して「このページのテーマは何か」「各セクションは何について述べているか」を理解します。
守るべきルールは明確です。h1はページに1つだけ使用し、ページの主題を表す最も重要な見出しにします。h2はh1の下位トピック、h3はh2の下位トピックというように、入れ子構造で階層を正しく保つことが重要です。h2の直下にh4が来るような「レベルの飛び」は、検索エンジンの構造理解を混乱させます。
<!-- ✅ 正しい見出し階層 -->
<h1>SEOに強いコーディングとは？</h1>
<h2>セマンティックHTMLの実践</h2>
<h3>見出しタグの階層ルール</h3>
<h3>セクショニング要素の使い方</h3>
<h2>構造化データの実装</h2>
<h3>JSON-LDの書き方</h3>
<!-- ❌ NGな見出し階層 -->
<h1>SEOに強いコーディングとは？</h1>
<h3>セマンティックHTMLの実践</h3> <!-- h2を飛ばしている -->
<h2>構造化データの実装</h2>
<h2>セマンティックHTMLの続き</h2> <!-- 順序が論理的でない -->実務的なアドバイスとして、h2とh3をメインで使い、必要に応じてh4まで使うのが一般的です。h5やh6は検索エンジンからの評価への影響が小さいため、通常のコンテンツページではほぼ使用しません。
リストタグ（ul・ol）は強調スニペット獲得のチャンス
手順やランキング、項目の列挙を本文に書くときは、改行や記号（「・」など）で済ませず、必ず<ul>（順不同リスト）または<ol>（順序付きリスト）でマークアップしましょう。リストタグで構造化された情報は、検索結果上部の強調スニペット（リスト形式）に採用されやすくなるという実利があります。
<!-- ❌ NG：テキストの羅列（構造が伝わらない） -->
<p>SEOコーディングの手順：・現状のコードを確認・セマンティックHTMLに修正・構造化データを実装</p>
<!-- ✅ 改善：olタグで「手順」であることを明示 -->
<h2>SEOコーディングの手順</h2>
<ol>
<li>現状のソースコードを確認する</li>
<li>セマンティックHTMLに書き換える</li>
<li>構造化データを実装する</li>
</ol>「〜の手順」「〜のポイント」という見出し（h2/h3）の直後にリストを置く構成は、検索エンジンが「質問と答えのセット」として認識しやすい形です。
メタタグの最適化 — title・meta description・OGPの書き方
メタタグは、検索結果ページ（SERP）やSNSでの表示に直接影響する要素であり、CTR（クリック率）を最も大きく左右するSEOコーディング要素です。
titleタグ — 30〜35文字・キーワード前方配置
<!-- ❌ NG：キーワードが後ろ、長すぎて切れる -->
<title>当社のWeb制作サービスについて｜株式会社〇〇のコーポレートサイト - SEO対策に強いコーディングで高品質なサイトを制作</title>
<!-- ✅ 改善：キーワード前方配置、30〜35文字 -->
<title>SEOに強いコーディングとは？実装テクニックをコード例付きで解説</title>titleタグの最適な文字数は30〜35文字です。これはGoogleの検索結果で省略されずに表示される長さです。また、主要キーワードはタイトルの前方に配置しましょう。ユーザーの視線は左から右に流れるため、キーワードが前にあるほうがクリック率が高まります。
meta description — 120〜160文字で内容＋行動喚起
<!-- ❌ NG：内容が曖昧で行動喚起がない -->
<meta name="description" content="SEOに関する情報をまとめたページです。">
<!-- ✅ 改善：具体的な内容＋行動喚起、120〜160文字 -->
<meta name="description" content="SEOに強いコーディング手法を実例コード付きで解説。セマンティックHTML、構造化データ、ページ速度最適化、JavaScript SEOまで網羅。Before/Afterのコード比較で、今日からすぐに実装できます。">meta descriptionは検索順位に直接は影響しませんが、CTRを大きく左右する重要な要素です。120〜160文字で、ページの内容を具体的に伝え、末尾に行動喚起（「今日から実装できます」「チェックリスト付き」など）を入れるとクリック率が向上します。
OGPタグ — SNSシェア経由の流入と被リンク獲得の起点
OGP（Open Graph Protocol）は、XやFacebookなどのSNSでページがシェアされたときの表示（タイトル・説明文・サムネイル画像）を制御するメタタグです。検索順位への直接の影響はありませんが、シェア時の見栄えが良いページは拡散されやすく、言及（サイテーション）や自然な被リンクを獲得する起点になるため、SEOコーディングの一部として必ず実装しておきたい要素です。
<!-- ✅ OGPの基本セット（headタグ内に記述） -->
<meta property="og:title" content="SEOに強いコーディングとは？実装テクニックを解説">
<meta property="og:description" content="Before/Afterのコード比較でSEOコーディングを解説。">
<meta property="og:type" content="article"> <!-- トップページは website -->
<meta property="og:url" content="https://example.com/seo-coding/">
<meta property="og:image" content="https://example.com/images/og-seo-coding.webp">
<meta property="og:site_name" content="サイト名">
<meta property="og:locale" content="ja_JP">
<!-- X（旧Twitter）用 -->
<meta name="twitter:card" content="summary_large_image">ポイントはog:imageです。推奨サイズは1200×630px（アスペクト比1.91:1）で、これより小さいとSNSのタイムラインで大きな画像カードとして表示されません。仕様の詳細はOpen Graph Protocol公式サイトで確認できます。WordPressの場合はSEOプラグイン（AIOSEOなど）が自動出力してくれるため、出力内容が意図通りかを確認しましょう。
画像のSEO最適化 — alt属性とパフォーマンスの両立
画像はWebページの視覚的な魅力を高めますが、検索エンジンは画像の内容を「見る」ことができません。代わりに、alt属性のテキストを読んで画像の内容を理解します。alt属性は画像SEOの基本であると同時に、アクセシビリティの観点からも必須の設定です。
<!-- ❌ NG例 -->
<img src="image1.jpg"> <!-- alt属性なし -->
<img src="chart.png" alt="画像"> <!-- 意味のないalt -->
<img src="seo.png" alt="SEO SEO対策 SEOコーディング SEO方法"> <!-- キーワード詰め込み -->
<!-- ✅ 改善例 -->
<img
src="/images/semantic-html-structure.webp"
alt="セマンティックHTMLの構造を示す図：header、nav、main、article、footerの配置"
width="800"
height="450"
loading="lazy"
decoding="async"
>改善例のポイントを解説します。alt属性には画像の内容を具体的に記述し、キーワードの不自然な詰め込みは避けます。widthとheight属性を指定することで、画像読み込み時のレイアウトシフト（CLS）を防ぎ、Core Web Vitalsのスコア改善につながります。loading="lazy"はファーストビュー外の画像を遅延読み込みし、初期表示速度を向上させます。画像形式はWebPを使うことで、JPEGと比べてファイルサイズを25〜35%削減できます。
内部リンクのコーディング — aタグの書き方でSEO効果が変わる
内部リンクは、サイト内のページ間のリンクジュース（SEO評価）の受け渡しと、検索エンジンのクロール導線を構築する重要なSEO要素です。しかし、aタグの書き方次第で、SEO効果は大きく変わります。
<!-- ❌ NG：アンカーテキストが曖昧 -->
<p>詳しくは<a href="/structured-data-markup/">こちら</a>をご覧ください。</p>
<!-- ✅ 改善：アンカーテキストにリンク先の内容を反映 -->
<p>具体的な実装方法は「<a href="/structured-data-markup/">構造化データマークアップ完全ガイド</a>」で解説しています。</p>
<!-- ❌ NG：JavaScriptでの遷移（クローラーがリンクを認識できない） -->
<div onclick="location.href='/about'">会社概要</div>
<!-- ✅ 改善：標準のaタグを使用 -->
<a href="/about">会社概要</a>最も重要なポイントはアンカーテキストです。「こちら」「詳しくはこちら」のような曖昧なテキストではなく、リンク先ページの内容がわかる具体的なテキストを使いましょう。Googleはアンカーテキストを「リンク先ページの内容を示すシグナル」として利用するため、適切なアンカーテキストはリンク先ページのSEO評価を高めます。
外部リンクの場合は、信頼できるサイトへのリンクにrel="noopener noreferrer"とtarget="_blank"を付与します。ユーザー生成コンテンツや広告リンクにはrel="nofollow"またはrel="sponsored"を追加して、リンクジュースの流出を制御しましょう。
構造化データの実装 — JSON-LDでリッチリザルトを獲得する
構造化データとは、Webページのコンテンツの意味を検索エンジンが機械的に理解できる形式で記述したデータです。JSON-LD（JavaScript Object Notation for Linked Data）形式で<head>タグ内または<body>タグ内に記述するのが、Googleが推奨する実装方法です。
構造化データを正しく実装すると、検索結果にリッチリザルト（FAQ、レビュー星評価、パンくずリストなど）が表示される可能性が高まり、CTRの大幅な向上が期待できます。当サイトでは、全ページにArticleスキーマとBreadcrumbListスキーマを実装し、主要な記事にはFAQPageスキーマも追加しています。
ブログ記事ページ用のArticle + BreadcrumbList構造化データ：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "SEOに強いコーディングとは？実装テクニックをコード例付きで解説",
"author": {
"@type": "Person",
"name": "著者名",
"url": "https://example.com/author/profile"
},
"publisher": {
"@type": "Organization",
"name": "サイト名",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"datePublished": "2026-01-15",
"dateModified": "2026-07-21",
"image": "https://example.com/images/seo-coding.webp",
"description": "SEOに強いコーディング手法をコード例付きで解説"
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "ブログ",
"item": "https://example.com/blog/"
},
{
"@type": "ListItem",
"position": 3,
"name": "SEOコーディング",
"item": "https://example.com/blog/seo-coding/"
}
]
}
</script>構造化データの実装後は、Googleのリッチリザルトテストで必ず検証しましょう。エラーがあるとリッチリザルトが表示されません。構造化データの各スキーマタイプの詳細な実装方法は「構造化データマークアップ完全ガイド」で網羅的に解説しています。
ページ速度最適化のコーディングテクニック — Core Web Vitals対応
ページの表示速度は、Googleが公式にランキング要因として明言している数少ない要素の一つです。Core Web Vitalsの3指標はLCP（表示速度）・INP（応答性）・CLS（視覚的安定性）です。注意したいのは、応答性の指標が2024年3月にFIDからINP（Interaction to Next Paint）へ正式に置き換えられたこと。古い解説記事にはFIDのまま説明しているものも多いため、これから対策するならINP（良好の目安：200ミリ秒以内）を基準にしましょう。ここでは、コーディングレベルで実装できる速度最適化テクニックを紹介します。
CSSの最適化 — クリティカルCSSでLCPを改善
<!-- ❌ NG：すべてのCSSを同期的に読み込み -->
<link rel="stylesheet" href="/css/all-styles.css">
<link rel="stylesheet" href="/css/animations.css">
<link rel="stylesheet" href="/css/print.css">
<!-- ✅ 改善：クリティカルCSSのインライン化 + 非クリティカルCSSの非同期読み込み -->
<style>
/* クリティカルCSS：ファーストビューの表示に必要な最小限のスタイル */
body { font-family: 'Noto Sans JP', sans-serif; margin: 0; }
header { background: #1a365d; color: #fff; padding: 1rem; }
main { max-width: 800px; margin: 0 auto; padding: 2rem 1rem; }
h1 { font-size: 1.75rem; line-height: 1.4; }
</style>
<!-- 非クリティカルCSSは非同期で読み込み -->
<link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<link rel="stylesheet" href="/css/print.css" media="print">クリティカルCSS（ファーストビューの描画に必要なCSS）をHTMLにインライン化することで、外部CSSファイルの読み込みを待たずに初期描画が開始されます。これによりLCP（Largest Contentful Paint）のスコアが大幅に改善します。実際に当サイトでは、この手法でLCPを3.2秒から1.8秒に短縮できました（旧サイト構成時の実測値）。
JavaScriptの最適化 — defer/asyncでレンダリングブロックを防ぐ
<!-- ❌ NG：headタグ内での同期的なJS読み込み -->
<head>
<script src="/js/analytics.js"></script>
<script src="/js/main.js"></script>
</head>
<!-- ✅ 改善：defer/asyncの活用 -->
<head>
<!-- 分析用JSは非同期で読み込み（表示をブロックしない） -->
<script src="/js/analytics.js" async></script>
</head>
<body>
<!-- メインJSはDOMの解析完了後に実行 -->
<script src="/js/main.js" defer></script>
</body>defer属性を使うと、HTMLの解析と並行してJSファイルをダウンロードし、解析完了後に実行します。asyncはダウンロード完了次第即座に実行されるため、実行順序が重要でないスクリプト（アナリティクスなど）に適しています。どちらもHTMLの解析をブロックしないため、ページの初期表示速度が向上します。長時間メインスレッドを占有するJavaScriptを減らすことは、INPの改善にも直結します。
画像のパフォーマンス最適化 — picture要素とsrcset
<!-- ✅ レスポンシブ画像の最適な実装 -->
<picture>
<!-- WebP対応ブラウザにはWebPを配信 -->
<source
type="image/webp"
srcset="/images/hero-400w.webp 400w,
/images/hero-800w.webp 800w,
/images/hero-1200w.webp 1200w"
sizes="(max-width: 600px) 100vw, 800px"
>
<!-- フォールバック用のJPEG -->
<img
src="/images/hero-800w.jpg"
alt="SEOコーディングの概念図"
width="800"
height="450"
loading="lazy"
decoding="async"
>
</picture><picture>要素を使うことで、ブラウザの対応状況に応じて最適な画像形式（WebP / JPEG）を自動的に選択させることができます。さらにsrcsetとsizes属性で、画面幅に応じた適切なサイズの画像を配信し、不必要に大きな画像のダウンロードを防ぎます。
JavaScript SEO — SPAとSSR/SSGの選択がSEOを左右する
React、Vue.js、Next.jsなどのJavaScriptフレームワークを使用している場合、JavaScript SEOへの対応は避けて通れません。GooglebotはJavaScriptを実行してレンダリングする能力を持っていますが、いくつかの制限があります。
| レンダリング方式 | SEO評価 | 初期表示速度 | 実装の複雑さ | 適するケース |
|---|---|---|---|---|
| SSG（静的生成） | ◎ 最高 | ◎ 最速 | ○ 中 | ブログ、ドキュメントサイト |
| SSR（サーバーサイドレンダリング） | ◎ 最高 | ○ 良い | △ 高い | ECサイト、動的コンテンツ |
| CSR（クライアントサイドレンダリング） | △ リスクあり | × 遅い | ○ 低い | 管理画面、ログイン後エリア |
SEOを重視するサイトでは、SSG（Static Site Generation）またはSSR（Server Side Rendering）を強く推奨します。CSR（Client Side Rendering）のみのSPA（シングルページアプリケーション）は、Googlebotのレンダリング処理に依存するため、インデックスの遅延や不完全なインデックスのリスクがあります。
当サイトの実体験を共有すると、scale-basics.comは当初Next.jsのSSG方式で構築し、2026年7月に運営体制の変更に伴いWordPressへ移行しました。SSGもWordPress（PHPによるサーバーサイドレンダリング）も「完成したHTMLをクローラーに返す」という点は同じで、移行後もインデックスに問題は発生していません。移行時に重要だったのは、旧URL（/blog/xxx/）から新URL（/xxx/）への301リダイレクトを1本ずつ確実に設定し、URL資産（被リンク・インデックス評価）を引き継ぐことでした。フレームワークの選択そのものより、「クローラーが余計な処理なしにHTMLを読める状態か」「URL変更時に評価を引き継げているか」がSEOの本質です。
ソースコードで確認すべきSEOチェックポイント — 自社・競合の診断手順
前述の方法でソースコードを開けるようになったら、次は「どこを見るか」です。SEOに関わる情報はHTMLのhead内と本文の見出し構造に集中しているため、確認する順序を決めておくと短時間で診断できます。自社ページの不備を洗い出す用途にも、上位表示されている競合ページの実装を読み解く用途にも、同じ手順が使えます。
| 確認箇所 | 検索する文字列 | 見るポイント |
|---|---|---|
| タイトル | <title> |
対策キーワードが前方にあるか。30〜35文字程度に収まっているか |
| ディスクリプション | name="description" |
設定されているか。120〜160文字でクリックを促す内容か |
| 正規URL | rel="canonical" |
自己参照になっているか。意図しない別URLを指していないか |
| インデックス制御 | name="robots" |
noindexが意図せず残っていないか |
| 見出し構造 | <h1 / <h2 |
h1が1つか。h2からh3への階層が飛んでいないか |
| 構造化データ | application/ld+json |
実装の有無と@type。競合が何を実装しているかの確認にも使う |
| 画像 | <img |
alt属性が空でないか。loading属性の指定があるか |
| OGP | property="og: |
og:title・og:image・og:descriptionが揃っているか |
| 多言語対応 | hreflang |
多言語サイトの場合、相互参照が正しく設定されているか |
ソースを表示した状態でCtrl+F（MacはCmd+F）を押し、上表の「検索する文字列」を入力すれば該当箇所へ直接飛べます。9項目を順に見ても数分で終わるため、記事公開前のルーティンに組み込むと不備の見落としが減ります。
競合分析に使う場合は、狙っているキーワードで上位に表示されているページを3〜5本開き、同じ項目を横に並べて比較します。とくに構造化データの@typeと見出し構成は、そのキーワードでGoogleが評価している形式を推測する手がかりになります。個別のタグの書き方はSEO対策に必須のHTMLタグ一覧、構造化データの詳細は構造化データマークアップ完全ガイドにまとめています。
注意点として、「ページのソースを表示」で見えるのはサーバーが返した素のHTMLであり、JavaScriptで後から挿入される要素は含まれません。メタタグや構造化データをJavaScriptで生成しているサイトでは、前述の「JavaScript SEO」で触れたとおり、デベロッパーツールの「Elements」タブでレンダリング後のDOMも確認する必要があります。素のHTMLとレンダリング後で内容が食い違う場合、Googleがどちらを見ているかで評価が変わります。
コーディング品質のチェックに使える無料ツール5選
SEOコーディングは「書いて終わり」ではなく、ツールでの検証までがセットです。当編集部が実際に使っている無料ツールを5つ紹介します。
- リッチリザルトテスト：構造化データが正しく認識されるかをGoogle公式ツールで検証。エラー0件が公開の合格ライン。
- PageSpeed Insights：Core Web Vitals（LCP・INP・CLS）のラボデータと、実際のユーザーの体験データ（CrUX）を確認できる。
- Markup Validation Service（Nu Checker）：HTML Living Standard基準の文法チェック。閉じタグ漏れや属性の誤用を検出。
- Search ConsoleのURL検査：Googleが実際にページをどうレンダリング・インデックスしたかを確認できる唯一のツール。
- Lighthouse（Chrome DevTools内蔵）：F12→「Lighthouse」タブ。パフォーマンス・アクセシビリティ・SEOを非公開ページ含めローカルで総合監査できる。
ここで一つ、当サイトの検証結果を正直に共有します。この記事のページをNu Checkerにかけたところ、エラー10件・警告38件が検出されました（2026年7月21日検証）。内訳はWordPressテーマ由来のaria-label属性の誤用などで、記事コンテンツ自体のエラーはゼロでした。実はGoogleは多少のHTML文法エラーがあってもページを解釈できるため、文法エラーの数そのものは順位を直接左右しません。ただし、閉じタグ漏れでDOM構造が壊れるレベルのエラーや、構造化データのエラーはインデックスやリッチリザルトに実害が出るため、優先的に修正すべきです。「エラー0を目指して消耗する」より「実害のあるエラーから直す」が実務的な判断です。
【実測】当サイトのSEOコーディング検証データ
本記事で解説したテクニックを実装している当サイト自身の計測結果を公開します（2026年7月21日計測）。
| 項目 | 実測値 | 計測方法・備考 |
|---|---|---|
| TTFB（サーバー応答時間） | 平均0.19秒（0.16〜0.22秒） | curlで3回計測。Googleの目安は0.8秒以内 |
| HTML転送サイズ | 83KB | 本記事ページのHTML本体 |
| LCP改善実績 | 3.2秒 → 1.8秒 | クリティカルCSSインライン化による短縮（旧構成時） |
| HTML文法チェック | エラー10件（テーマ由来） | W3C Nu Checker。記事コンテンツ由来のエラーは0件 |
| 構造化データ | 全ページ実装 | Article + BreadcrumbList（JSON-LD） |
TTFB（Time to First Byte）はCore Web Vitalsの3指標には含まれませんが、LCPの土台になる数値です。web.devのガイドでは0.8秒以内が「良好」とされており、当サイトはその4分の1程度に収まっています。どれだけフロントのコーディングを最適化しても、サーバー応答が遅ければLCPは改善しないため、速度対策は「サーバー→HTML→CSS/JS→画像」の順に上流から確認するのが効率的です。
SEOコーディング総合チェックリスト【20項目】
以下のチェックリストで、自サイトのコーディングがSEO要件を満たしているか確認しましょう。
| カテゴリ | チェック項目 | 優先度 |
|---|---|---|
| セマンティックHTML | ☐ header/nav/main/article/footer を使用している | ★★★★★ |
| セマンティックHTML | ☐ h1〜h6の階層がレベル飛びなく正しい | ★★★★★ |
| セマンティックHTML | ☐ h1はページに1つだけ使用 | ★★★★★ |
| セマンティックHTML | ☐ 列挙・手順はul/olタグでマークアップ | ★★★☆☆ |
| セマンティックHTML | ☐ html要素にlang=”ja”を設定 | ★★★★☆ |
| メタタグ | ☐ titleが30〜35文字でKW前方配置 | ★★★★★ |
| メタタグ | ☐ meta descriptionが120〜160文字で行動喚起含む | ★★★★☆ |
| メタタグ | ☐ canonicalが正しく設定されている | ★★★★☆ |
| メタタグ | ☐ OGP（og:title/og:image等）を設定済み | ★★★☆☆ |
| メタタグ | ☐ og:imageが1200×630pxで用意されている | ★★★☆☆ |
| 画像 | ☐ すべての画像にalt属性が設定されている | ★★★★★ |
| 画像 | ☐ width/height属性でCLS対策済み | ★★★★☆ |
| 画像 | ☐ WebP形式を使用している | ★★★☆☆ |
| リンク | ☐ 内部リンクに意味のあるアンカーテキストを使用 | ★★★★☆ |
| 構造化データ | ☐ Article/BreadcrumbListスキーマを実装済み | ★★★★☆ |
| 構造化データ | ☐ リッチリザルトテストでエラー0件 | ★★★★★ |
| パフォーマンス | ☐ JS/CSSにdefer/async/preloadを使用 | ★★★★☆ |
| パフォーマンス | ☐ LCPが2.5秒以内・INPが200ミリ秒以内 | ★★★★★ |
| パフォーマンス | ☐ TTFBが0.8秒以内 | ★★★★☆ |
| JS SEO | ☐ SSGまたはSSRを採用（CSRのみを避ける） | ★★★★☆ |
まとめ — SEOに強いコーディングは「基礎の積み重ね」
SEOに強いコーディングは、特別なテクニックではなく、Webの標準仕様を正しく使いこなす基礎の積み重ねです。セマンティックHTMLを使い、メタタグとOGPを最適化し、構造化データを実装し、ページ速度を改善する。一つひとつは地味な作業ですが、当サイトの実測データが示すとおり、これらの積み重ねは表示速度やインデックスの精度として確実に数値に表れます。
まずは上記の20項目チェックリストで現状を確認し、★5つの最優先項目から対応しましょう。HTMLタグの詳しい一覧は「SEO対策に必須のHTMLタグ一覧」で、構造化データの実装ガイドは「構造化データマークアップ完全ガイド」で確認できます。Web制作プロジェクト全体にSEOを組み込む方法は「Web制作にSEOを組み込む方法」で解説しています。
本記事は、scale-basics編集部が自社サイトの構築・運営・計測を通じて得た知見と、Google公式ドキュメント（SEOスターターガイド、JavaScript SEOの基本、構造化データガイドライン）に基づいて執筆しています。実測データの計測日：2026年7月21日。
