SEOコーディングとは？HTMLタグの書き方を自サイトの実測で検証

この記事でわかること

SEOコーディングとは？検索エンジンにページの意味を伝える書き方

SEOコーディングとは、検索エンジンがページをクロール・インデックスしやすく、内容と構造を正しく理解できるようにHTMLを書くことです。titleの書き方、リンクの形式、noindexの有無といったコード上の判断が、ページが検索結果に出るかどうかや、どう表示されるかを左右します。キーワード選定やコンテンツ作りも含めた施策全体の中での位置づけは、SEO対策の基本と実践手順の全体像で整理しています。

「SEOコーディング」という言葉に公式の定義はありませんが、上位の解説記事やGoogleのAIによる概要が挙げる内容はほぼ共通しています。セマンティックなタグで骨組みを作る、head内のメタ情報を整える、見出し・画像・リンクを正しく書く、構造化データと表示速度に配慮する、そしてツールで確認する、の5つです。この記事もこの順で解説します。

SEOでHTMLが重要な2つの理由

1つ目は、検索エンジンにページの内容が伝わるかどうかがHTMLで決まるからです。Googleが検索結果のタイトルリンクに使う材料の筆頭はtitle要素で、ほかにh1などの見出しやog:titleも使われます。リンクはhref付きのaタグでないと確実にはたどられず、noindexやcanonicalはインデックスの扱いを直接決めます。どれもHTMLの中にある要素です。

2つ目はユーザビリティです。見出し・リスト・表が意味どおりにマークアップされたページは、流し読みしやすく、スクリーンリーダーでも見出し間を移動できます。読みやすさは、検索から来たユーザーがページにとどまるかどうかに直結します。ChatGPTやGeminiなどのAI検索もHTMLから文章を取り出すため、構造が整理されたページは内容を取り違えられにくくなります。AI検索への対応はLLMO（AI検索最適化）の解説で扱っています。

HTMLは構造、CSSは見た目を担当する

Webページは主にHTMLとCSSでできています。HTMLは「ここが見出し」「ここが段落」「ここが画像」という文書の構造と意味を書く言語で、CSSは文字の大きさや色、レイアウトといった見た目を指定する言語です。

起きやすい失敗が、見た目のためにタグを選んでしまうことです。「文字を大きくしたいからh2を使う」「見出しっぽく見えればよいのでdivに太字のCSSを当てる」といった書き方は、画面上は同じに見えても、前者は見出しでない箇所を見出しと宣言し、後者は見出しを見出しと宣言していません。タグは意味で選び、見た目はCSSで整える。これがSEOコーディングの出発点です。

準拠すべき標準はHTML Living Standard（WHATWG）

現在のHTMLの標準は、WHATWGが策定するHTML Living Standardです。W3CのHTMLのページ自身が、WHATWGの仕様を「現在のHTML標準」とし、それ以前に公開されたHTML仕様はすべてこれに置き換えられたと明記しています。2019年にW3CとWHATWGが結んだ覚書でも、HTMLとDOMは主にWHATWGで策定するとされました。

そのため「W3Cの基準に沿って書く」「HTML5の書き方」という説明は、今では正確ではありません。バージョン番号を持たず継続的に更新される仕様なので、古い解説書の書き方が現在は非推奨になっている場合もあります。迷ったときはHTML Living Standardを確認します。

Googleは厳密な文法に依存しない — それでも正しく書く理由

Googleは、HTMLの文法が正しいか（バリデーションを通るか）に順位を依存させていません。GoogleのSEOスターターガイドは、ウェブの多くは正しいHTMLで書かれていないため、Google検索がHTML仕様に埋め込まれた意味に頼れることはほとんどない、と説明しています（英語版の原文は「The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.」）。W3Cのチェックツールでエラーを0にすること自体は、順位を上げる手段ではありません。

それでも正しく書くべきなのは、Googleがはっきり使っている要素がHTMLの中にあり、文法の崩れがそれらを壊すことがあるからです。閉じタグの漏れで本文の範囲がずれる、head内に置くべきタグが本文側に出てしまう、構造化データのJSONが壊れる、といったエラーは実害につながります。本記事では「Googleが公式に使うと説明している要素」を優先し、そのうえで読者とアクセシビリティのための書き方を加えていきます。

基本はセマンティックコーディング — 意味のあるタグでページの骨組みを作る

セマンティックコーディングとは、<div>や<span>のような意味を持たないタグだけで組むのではなく、<header>・<nav>・<main>・<article>・<footer>といった意味のあるタグで「ページのどこに何があるか」を示す書き方です。本文側のSEOコーディングは、この考え方に尽きます。

header・nav・main・article・footerの役割

ページの骨組みを作る主なセマンティックタグ

タグ	表すもの	使いどころ
<header>	導入部・ヘッダー	サイト名・ロゴ・グローバルナビゲーション、記事冒頭のタイトル周り
<nav>	主要なナビゲーション	グローバルメニュー、パンくずリスト、目次
<main>	ページの主要な内容	1ページに1つ。サイト共通部分（ヘッダー・サイドバー・フッター）を含めない
<article>	それだけで完結するコンテンツ	ブログ記事、ニュース記事、商品カード
<section>	見出しを持つまとまり	記事内の章。原則として見出しとセットで使う
<aside>	本題から独立した補足	サイドバー、関連記事
<footer>	末尾の情報	著作権表示、運営者情報、サイトマップへのリンク

Before/After：div多用のHTMLを意味のあるタグに書き換える

Before（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">&copy; 2026</div>
</div>

After（セマンティックHTML）

<header>
  <a href="/">
    <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>&copy; 2026</p>
</footer>

2つのコードはCSSで同じ見た目にできますが、Afterは<header>がヘッダー、<nav>がナビゲーション、<main>がページの主要部分、<article>が記事本文であることを宣言しています。記事タイトルも<div class="title">ではなく<h1>になりました。スクリーンリーダーはこれらを頼りに「本文へ移動」「ナビゲーションへ移動」ができるため、アクセシビリティの面ではっきりした差が出ます。

なお、<header>にrole="banner"、<main>にrole="main"のように同じ意味のrole属性を重ねて書く必要はありません。後述する当サイトの点検では、この冗長なrole属性がNu Html Checkerの警告として出ました。

SEOを意識したHTMLの基本テンプレート（短縮版）

SEOに関わる要素がHTMLのどこに入るのかを、1枚で確認しておきましょう。設定の多くは<head>内に集まり、本文側は見出し・段落・リスト・画像・リンクの書き方が中心です。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>SEOコーディングとは？HTMLタグの書き方を解説｜サイト名</title>
  <meta name="description" content="ページ固有の要約。何がわかるかを具体的に書く。">
  <link rel="canonical" href="https://example.com/seo-coding/">
  <meta property="og:title" content="SEOコーディングとは？HTMLタグの書き方を解説">
  <meta property="og:image" content="https://example.com/images/og-seo-coding.webp">
  <script type="application/ld+json">{ "@context": "https://schema.org", "@type": "BlogPosting", "headline": "SEOコーディングとは？" }</script>
</head>
<body>
  <header>…サイト名・ナビゲーション…</header>
  <main>
    <article>
      <h1>SEOコーディングとは？</h1>
      <h2>大見出し</h2>
      <p>本文…</p>
    </article>
  </main>
  <footer>…</footer>
</body>
</html>

OGPの全項目やパンくずリストまで入れたコピペ用の完全版は、SEO対策済みHTMLテンプレートにまとめています。以下では、head内から順に1つずつ書き方を見ていきます。

head内のタグ — title・meta description・canonical・robots・viewport・OGPの判断基準

<head>内のタグは画面に表示されませんが、検索結果の表示やインデックスの扱いを決める指示書です。誤ったときの影響が最も大きいので、本文より先に点検します。各タグの属性や書式の一覧はSEO対策に必須のHTMLタグ一覧に任せ、ここでは「どう書けば正しいと言えるか」の判断基準に絞ります。

titleタグ — 判断基準は「固有・具体的・前方にキーワード」

<!-- NG：定型文が先頭、キーワードの詰め込み、長すぎて省略される -->
<title>株式会社〇〇公式サイト｜SEO SEO対策 SEOコーディング SEO会社 Web制作 ホームページ制作</title>

<!-- OK：ページ固有の内容、主要キーワードを前方に -->
<title>SEOコーディングとは？HTMLタグの書き方を解説｜サイト名</title>

Googleのタイトルリンクのドキュメントが求めているのは、すべてのページに<title>要素を設定し、説明的で簡潔にすること、「ホーム」のような曖昧な語や不必要に長い文、キーワードの詰め込みを避けることです。長さに上限はなく、検索結果では端末の幅に合わせて省略されます。そのため30〜35文字程度に収め、主要キーワードを前方に置くのが実務上の目安になります。

もう1つの判断基準はtitle・h1・og:titleがそろっているかです。同ドキュメントは、タイトルリンクの材料としてtitleのほかにh1などの見出しやog:title、ページへのリンクのアンカーテキストも挙げています。食い違っていると、意図しない文言に書き換えられやすくなります。

meta description — 順位要因ではなく、スニペットとクリック率に効く

meta descriptionは順位を直接上げる要素ではなく、判断基準は「検索結果の説明文として採用されたときにクリックしたくなるか」です。Googleのスニペットのドキュメントによると、Googleは主にページ上のコンテンツから説明文を作り、descriptionのほうがページを的確に表している場合にそれを使います。長さに上限はなく、表示時に省略されます。

実務では120〜160文字程度で、そのページで何がわかるかを具体的に書きます。同ドキュメントは、全ページで同じか似た説明文を使うと個々のページが検索結果に出たときに役に立たないとして、ページごとに内容を正確に表す説明文を勧めています。

canonical — 迷ったら「自己参照の絶対URL」、統合したいならリダイレクト

同じ内容が複数のURLで表示できるとき（httpとhttps、末尾スラッシュの有無、計測用パラメータなど）、どれを代表として扱ってほしいかを伝えるのがcanonicalです。Googleの重複URLの統合のドキュメントは、rel=”canonical”を「強いシグナル」と位置づけ、相対パスではなく絶対URLで書くよう勧めています。正規のページには自分自身を指すcanonicalを置くのが基本です。

判断に迷うのは「canonicalで足りるか」です。canonicalは命令ではなくシグナルなので、指定と違うURLが代表に選ばれることもあります。同ドキュメントは、代表URLの判断に影響する方法を強い順に並べたとき、リダイレクトを最初に挙げています。URLそのものを1つにまとめたいなら、canonicalより301リダイレクトを検討します。詳しくはcanonicalタグによるURL正規化の解説と301・302リダイレクトの違いと設定方法を参照してください。

meta robots（noindex）とrobots.txt — 止めたいのはクロールかインデックスか

ページを検索結果に出さないための指示がnoindexで、判断基準は「止めたいのはクロールか、インデックスか」です。Googleのrobotsメタタグのドキュメントは、robots.txtでクロールを禁止したページでは、ページ内のインデックスに関する指示が読まれず無視されると説明しています。

<!-- 検索結果に出したくないページのheadに書く（公開ページに残っていないか必ず確認） -->
<meta name="robots" content="noindex">

つまり「robots.txtでブロックすれば検索結果から消える」は誤解です。2026年7月には、robots.txtでDisallowしていたClaudeの共有チャットがGoogle検索にインデックスされ、「Disallowはnoindexの代わりにならない」とSearch Engine Journalが指摘しました。クロールを止めたいならrobots.txt、インデックスを止めたいならnoindexと使い分けます。robots.txt側の書き方はrobots.txtの書き方ガイドで解説しています。コーディング上の事故で多いのは、開発環境で付けたnoindexが本番公開後も残っているケースなので、公開時のチェック項目に必ず入れておきます。

viewport — モバイルファーストインデックスとレスポンシブの前提

Googleのモバイルファーストインデックスのドキュメントによると、Googleはインデックス登録とランキングにモバイル版のコンテンツを使い、実装と保守が最も簡単な方法としてレスポンシブウェブデザインを推奨しています。width=device-widthを含むviewportの指定は、その前提となる1行です。

判断基準はスマホ表示でコンテンツを削っていないかです。同ドキュメントは、モバイル版にもPC版と同じコンテンツを含めるよう求めています。表示スペースが足りない場合は、削らずにアコーディオンやタブで折りたたみます。

OGP — og:titleと画像がページの内容と合っているか

OGP（Open Graph Protocol）は、XやFacebookなどでページが共有されたときのタイトル・説明文・画像を指定するタグです。検索順位を直接上げる要素ではありませんが、前述のとおりog:titleはGoogleのタイトルリンクの材料の1つでもあります。判断基準は、og:titleとog:descriptionがページ固有か、og:imageが内容に合っていて十分な大きさかの2点です。画像の大きさは、Metaの開発者向けドキュメントが高解像度の端末向けに1200×630ピクセル以上を勧めています。og:の各プロパティと確認ツールはOGPの設定方法と画像サイズの解説にまとめています。

なお、meta keywordsは設定不要です。SEOスターターガイドは「Google検索はキーワードのメタタグを使用しない」と明記しています。

実例：このページのhead（2026年10月11日・書き直す前の状態）

当サイトはWordPressで運用しており、head内のタグはSEOプラグイン（AIOSEO）とテーマが出力しています。書き直す前のこのページの本番HTMLをcurlで取得し、SEOに関わる行だけを抜き出したのが次のコードです（descriptionは途中を省略）。

<html dir="ltr" lang="ja" prefix="og: https://ogp.me/ns#">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>SEOコーディングとは？HTMLの書き方をコード例と実測で解説</title>
<meta name="description" content="SEOコーディングとは、検索エンジンとユーザーにページの意味が正しく伝わるHTMLの書き方です。…" />
<link rel="canonical" href="https://scale-basics.com/seo-coding/" />
<meta name="robots" content="max-image-preview:large" />
<meta property="og:type" content="article" />
<meta property="og:title" content="SEOコーディングとは？HTMLの書き方をコード例と実測で解説" />
<meta property="og:url" content="https://scale-basics.com/seo-coding/" />
<meta property="og:image" content="https://scale-basics.com/blog/wp-content/uploads/2026/03/seo-coding-1-scaled.jpg" />
<meta name="twitter:card" content="summary_large_image" />
<!-- JSON-LD：AIOSEOの @graph に BlogPosting / BreadcrumbList / Organization / Person / WebPage / WebSite、別のscriptにFAQPage -->

canonicalは自己参照の絶対URL、robotsはnoindexを含まない、viewportとog:系もそろっている、という状態でした。一方で、このとき本文のh1は「…コード例と実測データで解説」で、titleの「…コード例と実測で解説」と末尾がわずかに違っていました。プラグイン任せでも、titleとh1がそろっているかはソースを見ないと気づけません。

本文のタグ — 見出し・リスト・強調・表・引用

本文のマークアップは「内容の種類に合ったタグを選ぶ」ことが基本です。見出しはh1〜h6、列挙はリスト、比較は表、他者の文章は引用タグで書きます。

見出しタグ（h1〜h6） — 「h1は1つ」の公式見解と、それでも階層を守る理由

<!-- OK：読者が追いやすい見出し階層 -->
<h1>SEOコーディングとは？</h1>
  <h2>head内のタグ</h2>
    <h3>titleタグ</h3>
    <h3>canonical</h3>
  <h2>本文のタグ</h2>
    <h3>見出しタグ</h3>

<!-- NG：文字を大きくしたいだけでh2を使う／h2の下にいきなりh4 -->
<h2>今だけ送料無料！</h2>
<h2>本文のタグ</h2>
  <h4>見出しタグ</h4>

見出しについては、通説と公式見解にずれがあります。「h1は1ページに1つ」「階層を飛ばすとSEOに悪い」とよく言われますが、SEOスターターガイドは、見出しを意味的な順番にするのはスクリーンリーダーにとっては素晴らしいことだが、Google検索の観点では順番どおりでなくても問題ない、と述べています。理想的な見出しの数もないとしています。

それでも当サイトがh1は1つ、h2→h3→h4と飛ばさないルールで書いているのは、読者が目次と見出しで内容を把握しやすく、スクリーンリーダーで見出し間を移動しやすく、複数人で編集しても構成が崩れにくいからです。見出しは「Googleのため」ではなく「読者と運用のため」に整える、と考えるのが正確です。h1はタイトルリンクの材料にもなるので、titleと内容をそろえておきます。

リストタグ（ul・ol・dl） — 列挙・手順・用語説明を構造で示す

<!-- NG：記号と改行だけの羅列 -->
<p>手順：・現状のコードを確認・セマンティックHTMLに修正・構造化データを実装</p>

<!-- OK：順番に意味がある手順は ol -->
<ol>
  <li>現状のソースコードを確認する</li>
  <li>セマンティックHTMLに書き換える</li>
  <li>構造化データを実装する</li>
</ol>

<!-- OK：「用語と説明」の組は dl -->
<dl>
  <dt>canonical</dt>
  <dd>重複URLのうち代表とするURLを示す指定</dd>
</dl>

手順やランキング、項目の列挙は、記号と改行で済ませずリストタグでマークアップします。順番に意味があれば<ol>、順不同なら<ul>、用語と説明の組なら<dl>です。「〜の手順」という見出しの直後に<ol>を置くと、読者が流し読みしやすく、検索エンジンやAI検索も手順のまとまりとして抜き出しやすくなります。

強調タグ（strong・em・b） — 乱用すると強調の意味が薄れる

<!-- OK：内容として重要な箇所だけを strong に -->
<p>本番公開前に、<strong>noindexが残っていないか</strong>を必ず確認します。</p>

<!-- NG：見た目を太くしたいだけで strong を多用 -->
<p><strong>今なら</strong><strong>無料</strong>で<strong>資料</strong>を<strong>配布中</strong></p>

HTMLの仕様上、<strong>は「重要性」、<em>は「強勢（その語を強めて読む）」、<b>は「重要性はないが目を引かせたい語」を表します。strongで囲めば順位が上がるわけではなく、1段落に何か所も使うと読者にとってどこが重要かわからなくなります。本当に重要な一文だけをstrongにし、装飾はCSSで行います。

表（table） — 画像ではなくHTMLの表で書く

<table>
  <caption>レンダリング方式の比較</caption>
  <thead>
    <tr><th scope="col">方式</th><th scope="col">初期HTMLに本文があるか</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">SSG・SSR</th><td>ある</td></tr>
    <tr><th scope="row">CSR</th><td>ない（JavaScript実行後に生成）</td></tr>
  </tbody>
</table>

料金表や比較表を画像1枚で載せると、中の文字は検索エンジンにもスクリーンリーダーにも読みにくくなります。<table>で書き、見出しセルには<th>、表題には<caption>を使います。行の見出しにはscope="row"を付けると、読み上げ時にどの行の値かが伝わります。WordPress 7.1でも、管理画面の投稿一覧で投稿タイトルの列を行見出し（th scope="row"）に変える変更が入りました（WordPress 7.1の投稿一覧のHTML構造変更。公開側のマークアップには影響しない変更です）。

引用（blockquote・cite） — 出典を明示して信頼性を示す

<blockquote cite="https://developers.google.com/search/docs/fundamentals/seo-starter-guide">
  <p>Google Search doesn't use the keywords meta tag.</p>
</blockquote>
<p>出典：<cite><a href="https://developers.google.com/search/docs/fundamentals/seo-starter-guide">Google検索セントラル「SEOスターターガイド」</a></cite></p>

他サイトの文章を引用するときは<blockquote>で囲み、出典名とリンクを添えます。引用部分と自分の文章の境目がHTML上でも明確になり、読者にとっても「どこからが一次情報か」がわかります。引用は必要な範囲にとどめ、自分の解説を主にします。

パンくずリストは、サイト階層の順番に意味があるので<nav>で囲んだ<ol>で書きます。BreadcrumbListの構造化データを併用する場合は、画面上のパンくずと構造化データの内容を一致させます。設置方法とSEO上の効果はパンくずリストの設置方法の解説にまとめています。個々のタグをもっと細かく確認したい場合はSEO対策に必須のHTMLタグ一覧を参照してください。

画像とリンクのタグ — alt属性・アンカーテキスト・rel属性の判断基準

画像はalt属性で、リンクはアンカーテキストで、それぞれ「何であるか」を検索エンジンに伝えます。どちらも書き方を誤ると、画像の内容が伝わらない、リンクがたどられないといった実害が出ます。属性の一覧はSEO対策に必須のHTMLタグ一覧に任せ、ここでは書き方の判断基準を整理します。

alt属性 — 「画像が見えない人に何と伝えるか」で書く。キーワードの詰め込みはNG

<!-- NG：キーワードの詰め込み -->
<img src="seo.png" alt="SEO SEO対策 SEOコーディング SEO方法">

<!-- OK：画像の内容を説明する -->
<img src="/images/semantic-html-structure.webp"
     alt="セマンティックHTMLの構造図：header、nav、main、article、footerの配置"
     width="800" height="450">

「altにもキーワードを入れる」と解説されることがありますが、ここは注意が必要です。Googleの画像SEOのドキュメントは、altを画像のメタデータとして最も重要な属性と位置づける一方で、altをキーワードで埋めるとユーザー体験を損ない、サイトがスパムと見なされる可能性があると明記しています。判断基準は「画像が見えない人に、この画像を何と説明するか」です。キーワードは、内容を自然に説明した結果として入る程度にとどめます。装飾だけの画像はaltを空（alt=""）にします。

同ドキュメントはCSSの背景画像はインデックスしないとも書いています。商品写真や図解など検索に出したい画像は、background-imageではなく<img>要素で置きます。

width・height属性と画像形式 — CLSを防ぎ、軽い形式で配信する

imgにwidthとheightを書くと、読み込み前に表示領域が確保され、レイアウトのずれ（CLS）を防げます。ファーストビュー外の画像にはloading="lazy"を付けて初期表示を軽くします。

形式は、Googleがimgのsrcで対応しているBMP・GIF・JPEG・PNG・WebP・SVG・AVIFから選びます。GoogleのWebPのページによると、WebPの非可逆圧縮画像は同等の画質のJPEGより25〜34%小さくなります。WordPressでは2026年8月リリースのWordPress 7.1で、画像の圧縮・リサイズがブラウザ内で行われるようになり、AVIFにもネイティブ対応しました。

aタグとアンカーテキスト — リンク先の内容を一言で言えているか

アンカーテキストはリンク先の内容を伝える手がかりで、判断基準は「リンクの文字だけ読んで、行き先の内容がわかるか」です。Googleのリンクに関するドキュメントは「Click here」「Read more」のような汎用的すぎる文言を悪い例に挙げ、説明的で簡潔な文言を勧めています。反対に、リンク先に関係するキーワードを片っ端から詰め込むことも避けるよう書いています（キーワードの詰め込みはスパムポリシー違反です）。画像をリンクにする場合は、画像のaltがアンカーテキストの役割を果たします。サイト内のどこからどこへリンクを張るかの設計はSEO内部リンク戦略の設計と実装で解説しています。

クロール可能なリンクの書き方 — href属性は必須

<!-- NG：hrefのないリンク（クローラーが確実にはたどれない） -->
<span onclick="location.href='/about/'">運営者情報</span>

<!-- OK：href属性を持つaタグ -->
<a href="/about/">運営者情報</a>

同ドキュメントは、Googleが通常クロールできるリンクはhref属性を持つ<a>要素だけで、hrefのないaタグやスクリプトのイベントでリンクのように動かしている要素からは、URLを確実には取り出せないと説明しています。JavaScriptで遷移を制御したい場合も、hrefは必ず残しておきます。

rel属性（nofollow・sponsored・ugc） — 付けるかどうかは「リンクの性質」で決める

判断基準は、そのリンクが「お金や対価が絡むか」「ユーザーが書いたものか」です。Googleの外部リンクの属性のドキュメントによると、広告や有料掲載のリンクにはsponsored、コメント欄やフォーラム投稿など、ユーザーが作成したコンテンツ内のリンクにはugc、どちらにも当てはまらずリンク先と関連付けたくない場合にnofollowを使います。有料リンクには以前はnofollowが推奨されており、現在も使えますが、sponsoredが推奨されています。信頼できる公式情報への通常の参照リンクには、これらの属性を付ける必要はありません。なお、target="_blank"に添えるrel="noopener noreferrer"はSEOではなくセキュリティとプライバシーのための指定です。

構造化データ・表示速度・JavaScript — 技術面のコーディング

タグの書き方に加えて、構造化データ・表示速度・JavaScriptの扱いもHTMLの書き方で決まります。いずれも詳しく扱うと1本の記事になるテーマなので、ここではコーディング上の要点に絞ります。

構造化データ（JSON-LD）の要点

構造化データは、ページの内容（記事・パンくず・商品など）を検索エンジンが機械的に理解できる形で補足するデータです。Googleが推奨する形式はJSON-LDで、headまたはbody内の<script type="application/ld+json">に書きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "SEOコーディングとは？HTMLタグの書き方を解説",
  "author": { "@type": "Person", "name": "著者名" },
  "datePublished": "2026-01-15",
  "dateModified": "2026-10-11"
}
</script>

WordPressではSEOプラグインがまとめて出力することが多く、当サイトの記事ページでもAIOSEOが1つのscriptの中にBlogPosting・BreadcrumbList・Organization・Person・WebPage・WebSiteをまとめて出力しています。構造化データを書いてもリッチリザルトの表示は保証されないこと、画面に表示されている内容と一致させることが基本です。種類ごとの書き方と検証方法は構造化マークアップの書き方と自サイト検証の記録で解説しています。

Core Web Vitals（LCP・INP・CLS）に効くコーディング

Core Web Vitalsは、表示速度（LCP）・応答性（INP）・視覚的な安定性（CLS）の3指標です。Googleのドキュメントが示す良好の目安は、LCP 2.5秒以内・INP 200ミリ秒未満・CLS 0.1未満です。応答性の指標は2024年3月にFIDからINPへ置き換えられました。

ページエクスペリエンスのドキュメントは「Core Web Vitalsはランキングシステムで使われている」としつつ、ページエクスペリエンスに単一のシグナルはないとも説明しています。スコアが良好なら上位表示されるというものではなく、コンテンツが同程度のページ同士で差がつく要素と捉えるのが妥当です。HTMLとCSS・JavaScriptの書き方で改善できるのは、主に次の3点です。

<!-- 1. クリティカルCSSのインライン化＋残りのCSSは非同期で読み込む -->
<style>
  /* ファーストビューの表示に必要な最小限のスタイル */
  body { margin: 0; font-family: sans-serif; }
  main { max-width: 800px; margin: 0 auto; }
</style>
<link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

<!-- 2. JavaScriptは defer / async で解析を止めない -->
<script src="/js/analytics.js" async></script>
<script src="/js/main.js" defer></script>

<!-- 3. 画面幅に合ったサイズの画像を選ばせる（srcは必ず残す） -->
<img src="/images/hero-800w.jpg"
     srcset="/images/hero-400w.webp 400w, /images/hero-800w.webp 800w"
     sizes="(max-width: 600px) 100vw, 800px"
     alt="SEOコーディングの概念図" width="800" height="450" fetchpriority="high">

1つ目は、ファーストビューの描画に必要なCSSだけをHTMLにインライン化し、外部CSSの読み込みを待たずに初期描画を始める方法です。すべてのCSSを直書きすると管理が難しくなりキャッシュも効かないため、インライン化はファーストビュー分に限ります。

2つ目のdeferは、HTMLの解析と並行してダウンロードし、解析完了後に記述順で実行します。asyncはダウンロードが終わり次第実行するので、実行順を問わないアクセス解析などに向きます。メインスレッドを長く占有するJavaScriptを減らすことは、INPの改善にもつながります。

3つ目のsrcsetとsizesは、画面幅に合った画像をブラウザに選ばせる指定です。画像SEOのドキュメントは、srcsetやpictureを理解しないブラウザやクローラーもあるため、src属性でフォールバックのURLを必ず指定するよう求めています。ファーストビューのメイン画像はLCPの対象になりやすいので、loading="lazy"を付けず、優先して読み込ませます。

レスポンシブ対応 — CSS側で画面幅に合わせる

viewportを指定したうえで、レイアウトはCSSのメディアクエリやFlexbox・Gridで画面幅に合わせます。固定幅のレイアウトはスマホで横スクロールや文字の縮小表示を生みます。

/* スマホを基準に書き、広い画面で段組みを増やす */
.post-list { display: grid; grid-template-columns: 1fr; gap: 16px; }
@media (min-width: 768px) {
  .post-list { grid-template-columns: repeat(2, 1fr); }
}
img { max-width: 100%; height: auto; }

スマホとPCで別々のHTMLを出し分けるより、同じHTMLをCSSで組み替えるほうが、前述の「モバイル版にもPC版と同じコンテンツを含める」という要件を自然に満たせます。

JavaScript SEO — 初期HTMLに本文があるかが分かれ目

React・Vue.js・Next.jsなどで作るサイトでは、JavaScriptの実行後にしか本文が現れない作りになっていないかが分かれ目です。GoogleのJavaScript SEOの基本によると、GoogleはJavaScriptを使うページを「クロール」「レンダリング」「インデックス登録」の段階で処理します。そのうえで、すべてのボットがJavaScriptを実行できるわけではないため、サーバーサイドレンダリングやプリレンダリングは今でも有効だと説明しています。

レンダリング方式とSEO上の扱いやすさ

方式	初期HTMLに本文があるか	SEO上の扱いやすさ	向いている用途
SSG（静的生成）	ある	扱いやすい	ブログ、ドキュメント
SSR（サーバーサイドレンダリング）・WordPress	ある	扱いやすい	EC、更新の多いメディア
CSR（クライアントサイドレンダリング）	ない	注意が必要	管理画面、ログイン後のエリア

CSRのページで最低限守るのは3点です。リンクはhref付きのaタグにすること、ページの切り替えは#/aboutのようなフラグメントではなくHistory APIで行うこと、そしてインデックスさせたいページの元のHTMLにnoindexを入れないことです。同ドキュメントは、Googleはnoindexを見つけるとレンダリングとJavaScriptの実行を省略する場合があり、JavaScriptでnoindexを外しても期待どおりに動かないことがあると説明しています。なお、「Googleのレンダリングは5秒まで」という定説は検証で否定されており、その経緯はレンダリング5秒説の検証とWRSの「仮想クロック」のニュースで紹介しています。

当サイトでも、このページの素のHTMLとレンダリング後の状態を比べました（2026年10月11日、書き直す前の本文）。サーバーが返した初期HTMLと、ブラウザ（Chromium）で開いてJavaScriptを実行し終えた後の状態とで、本文エリア内の見出しを比べたところ、書き直す前の本文の見出し（h2・h3）はどちらも45個で、文言も順番も完全に一致しました。違ったのは目次だけで、素のHTMLでは目次のリストが空、レンダリング後は45項目が並んでいました。当サイトの目次はテーマのJavaScriptが見出しから作っているためです。本文は初期HTMLにあり、補助的な目次だけをJavaScriptで作る、というのがJavaScript SEOの観点で安全な作りです。

当サイトの記事は、開設当初から /blog/ 配下のWordPressで配信しています（2026年7月まではルートに別途Next.js製の教材サイトがあり、教材の撤去に合わせて記事のURLを /blog/xxx/ から /xxx/ へ移し、301リダイレクトで引き継ぎました）。WordPressもSSG（静的サイト生成）も、サーバーから「完成したHTMLを返す」点は同じで、JavaScriptの実行を待たずに本文が読めます。サイト制作の工程全体にSEOを組み込む手順はWeb制作にSEOを組み込む方法で解説しています。

SEOでやってはいけないコーディング

SEOでやってはいけないコーディングは、検索エンジンだけに見せるための隠しテキスト・隠しリンク、キーワードの詰め込み、そして情報どうしが食い違う矛盾したメタデータの3つです。前の2つはGoogleのスパムポリシー違反にあたり、3つ目はスパムでなくても検索エンジンを迷わせます。

隠しテキスト・隠しリンク

Googleのスパムポリシーは、検索エンジンを操作する目的だけでユーザーに見えにくく置いたテキストやリンクを違反とし、例として次の書き方を挙げています。

• 白い背景に白い文字を置く、テキストを画像の背後に隠す
• CSSでテキストを画面の外に配置する、フォントサイズや不透明度を0にする
• 段落の中の目立たない1文字（ハイフンなど）だけをリンクにして隠す

/* NG：検索エンジンだけに読ませる目的でテキストを隠す（スパムポリシー違反） */
.seo-text { position: absolute; left: -9999px; }
.hidden-keywords { font-size: 0; }
.white-text { color: #fff; background: #fff; }

一方で、同ポリシーは、クリックで開閉するアコーディオンやタブ、スライダー、ツールチップ、スクリーンリーダー向けの補足テキストは違反にあたらないと明記しています。判断の基準は「ユーザーのために表示を切り替えているか」です。

キーワードの詰め込み（title・alt・見出し）

同じ語句を不自然なほど繰り返す、キーワードや地名を羅列したブロックを置く、といった書き方はキーワードの乱用としてスパムポリシー違反です。コーディングで起こりやすいのは、titleの末尾にキーワードを並べる、すべての画像のaltに同じキーワードを入れる、見出しにキーワードを機械的に足す、の3パターンです。どの要素も「その要素が本来説明すべき内容」を書けば、詰め込みにはなりません。

矛盾したメタデータ — BreadcrumbListの二重出力を直した例

当サイトでは、このページを含む全ページ種別で、パンくずリストの構造化データ（BreadcrumbList）が二重出力されていました。2026年10月11日に本番HTMLを確認したところ、SEOプラグイン（AIOSEO）の構造化データの中のBreadcrumbListと、テーマが別に出力しているBreadcrumbListの2つがありました。

経緯を調べると、AIOSEOはテーマ側の出力を作る前からBreadcrumbListを出しており、テーマに出力を足したときの確認漏れでした。AIOSEOが有効なときはテーマ側の出力を止めてAIOSEOに一本化し、同じ日に本番HTMLでBreadcrumbListが1つになったことを確認しています。修正後、このページをスキーママークアップ検証ツール（Schema Markup Validator）にかけた結果は、検出2件（BlogPostingとFAQPage）でエラー0・警告0でした。

同じ種類の構造化データが2つあり、中身が少しでも違えば、どちらを信じればよいかが曖昧になります。canonicalとnoindexを同じページに併用する、表示されている更新日と構造化データのdateModifiedがずれる、といった状態も同じ種類の問題です。GoogleのJohn Mueller氏も、矛盾したメタデータはどちらが優先されるか検証するのではなく直すべきだと述べています。プラグインとテーマを併用している場合は、新しく何かを出力する前に、同じものがすでに出ていないかを本番のソースで確認します。修正コードと原因の詳細は構造化マークアップの解説記事にまとめています。

SEOコーディングの確認方法 — ソースコードの見方とチェックツール

SEOコーディングは、本番のソースコードを見て確認するまでがセットです。特別なツールがなくてもブラウザだけで多くの項目を点検でき、文法や速度は無料のチェックツールで補えます。

ソースコードの見方 — 「ページのソースを表示」と「検証（DevTools）」の違い

• ページのソースを表示：ページ上で右クリック→「ページのソースを表示」（Chromeのショートカットは Windows が Ctrl+U、Mac が Cmd+Option+U）。サーバーが返した「素のHTML」を確認できます。
• 検証（デベロッパーツール）：右クリック→「検証」、またはF12キー（Macは Cmd+Option+I）→「Elements」タブ。JavaScriptの実行後の「レンダリング後のDOM」を確認できます。

この2つは一致しない場合があります。JavaScriptで後から本文を作っているサイトでは、ソース表示では本文が空なのにElementsには本文がある、という状態になります。前述のとおり、当サイトでは目次だけがこのパターンでした。本文や見出しまでソースに無い場合は、JavaScript SEOの問題を抱えている可能性があります。

ソースで確認すべきチェックポイント

ソースコードで見るべきSEOチェックポイント

確認箇所	検索する文字列	見るポイント
インデックス制御	name="robots"	noindexが意図せず残っていないか
タイトル	<title>	ページ固有か。主要キーワードが前方にあり、30〜35文字程度か
正規URL	rel="canonical"	自己参照の絶対URLか。別URLを指していないか
モバイル対応	name="viewport"	width=device-widthが指定されているか
ディスクリプション	name="description"	設定されているか。ページ固有の要約か
見出し構造	<h1 / <h2	h1がtitleと対応しているか。見出しだけで内容がわかるか
構造化データ	application/ld+json	@typeは何か。同じ種類が重複していないか。画面の内容と矛盾していないか
画像	<img	altが適切か。width・heightがあるか
OGP	property="og:	og:title・og:image・og:descriptionがそろっているか

ソースを表示した状態でCtrl+F（MacはCmd+F）を押し、表の「検索する文字列」を入力すれば該当箇所へ直接移動できます。9項目を順に見ても数分で終わるので、記事の公開前と、テーマやプラグインを更新した後のルーティンに組み込むと見落としが減ります。

無料チェックツール — Markup Validation Service・Another HTML-lint・PageSpeed Insightsほか

ソースの目視に加えて、無料のチェックツールで文法・速度・構造化データを確認します。W3CのMarkup Validation Service（Nu Html Checker）とAnother HTML-lint gatewayはHTMLの文法、PageSpeed Insightsは表示速度、Search ConsoleのURL検査はGoogleから見た状態を確認するツールです。

SEOコーディングの確認に使える無料ツール（2026年10月11日に提供を確認）

ツール	確認できること
Markup Validation Service（Nu Html Checker）	W3Cが提供するHTMLの文法チェック。閉じタグ漏れ、属性の誤用、不要なrole属性など
Another HTML-lint gateway	日本語で使えるHTMLの文法チェック（現在のバージョンはAnother HTML-lint 5）
PageSpeed Insights	LCP・INP・CLSのラボデータと、実際のユーザーのデータ（データが十分にある場合）
Search ConsoleのURL検査	Googleがページをどうクロール・インデックスしたか。noindexやcanonicalの扱い（要ログイン）
スキーママークアップ検証ツール（Schema Markup Validator）	構造化データの文法と、検出されたアイテムの一覧
リッチリザルトテスト	構造化データがGoogleのリッチリザルトの対象になるか

文法チェックの結果は「全部直すべきもの」ではありません。Nu Html CheckerのAboutページ自身が、このツールは合否を判定する認定の仕組みではなく、エラー0と出た文書でも後から新しいチェックが加わればエラーが出ることがある、と説明しています。表示を崩す・本文の範囲をずらす・head内の要素を壊すエラーから優先して直します。クロールやインデックスまで含めたサイト全体の点検項目はテクニカルSEOのチェックリスト60項目にまとめています。

【実測】当サイトの本番ページをチェックした結果

このページ（https://scale-basics.com/seo-coding/）を書き直す前の状態で、2026年10月11日に当サイトが実際に測った結果です。丸めた値には、括弧内に元の値を併記しています。

当サイトの本番ページの実測値（2026年10月11日・本記事URL・書き直す前の本文）

項目	実測値	計測方法・備考
TTFB（サーバー応答時間）	平均 約0.20秒（0.203秒。3回の値は0.275秒／0.172秒／0.163秒）	2026年10月11日10時06分、curlで3回計測。1回目はDNSの名前解決に0.082秒かかった。web.devの「良好」は0.8秒以下
HTMLサイズ	約189KB（193,460バイト）／gzip転送時 約61KB（62,580バイト）	同時刻にcurlで取得。HTML本体のみで、画像・CSS・JavaScriptは含まない
HTML文法チェック	エラー少なくとも8件・警告19件	Nu Html Checker（validator.nu）。報告された8件のうち記事本文内は1件、残り7件は本文の外（WordPress本体・テーマ・関連記事・サイドバーなど）。サイドバーの1件では、それより内側のエラー表示が省略されている
構造化データ	2件検出・エラー0・警告0	Schema Markup Validator。BlogPostingとFAQPage。BreadcrumbListは二重出力を修正後で1つ
素のHTMLとレンダリング後	書き直す前の本文の見出し（h2・h3）45個が完全に一致	初期HTMLとChromiumでの表示後を、本文エリア（.post-content）内に限って比較。目次だけがJavaScriptで生成

TTFBはCore Web Vitalsの3指標には含まれませんが、LCPの土台になる数値です。web.devのTTFBのガイドでは0.8秒以下が良好、1.8秒超が不良とされ、当サイトの3回はいずれも0.8秒を下回りました（計測は運営者のPCから日本国内の回線で行った3回のみです）。PageSpeed InsightsのAPIでLCPやCLSも測る予定でしたが、計測日はAPIの1日あたりの利用上限に達していて結果を取得できなかったため、この表には載せていません。

注目したいのはHTML文法チェックの1件です。記事本文内のエラーは、冒頭の「この記事でわかること」のブロックで、開始タグの無い</p>が出ていました。入稿したHTMLにはこの閉じタグは無く、WordPressが本文を出力する段階で付いたものです。このブロックは本記事でも使っているため、同じエラーは書き直した後も出ます。記事の書き手が正しく書いても、CMSの出力で文法エラーが生まれることがある、という実例です。残り7件のエラーと19件の警告も、アイキャッチ画像の属性の重複、サイドバー内のstyle要素、header・nav・main・footerに重ねたrole属性など、記事本文の外にありました。

SEOコーディング チェックリスト（20項目）

本記事の内容を、見出しの順に20項目のチェックリストにまとめました。優先度は「誤ったときにインデックスや検索結果の表示に直接影響するか」を基準にした当サイトの目安です。

SEOコーディング総合チェックリスト

区分	チェック項目	優先度
基本	html要素にlang=”ja”を設定している	中
基本	header・nav・main・article・footerで骨組みを作っている	中
head	インデックスさせたいページにnoindexが残っていない	最優先
head	titleがページ固有で、主要キーワードが前方にある（30〜35文字目安）	最優先
head	canonicalが自己参照の絶対URLになっている	高
head	viewportを指定し、スマホでもPCと同じ内容を表示している	高
head	meta descriptionがページ固有の要約になっている（120〜160文字目安）	中
head	OGP（og:title・og:image等）を設定し、titleと内容がそろっている	中
本文	h1はtitleと対応し、h2→h3→h4の階層を飛ばしていない	中
本文	列挙・手順はul・ol、用語説明はdlでマークアップしている	中
本文	strongは本当に重要な箇所だけ。表はtable、引用はblockquote	中
画像	内容を伝える画像に具体的なaltがある（装飾画像はalt=””）	高
画像	重要な画像はCSS背景ではなくimg要素で置き、width・heightを指定	高
リンク	リンクはhref付きのaタグで、アンカーテキストが具体的	最優先
リンク	広告リンクにsponsored、ユーザー投稿のリンクにugcを付けている	中
技術	構造化データはJSON-LDで、同じ種類が重複せず、画面の内容と一致している	高
技術	LCP 2.5秒以内・INP 200ミリ秒未満・CLS 0.1未満を目指している	高
技術	JS・CSSにdefer・async・preloadを使い、TTFBが0.8秒以下	中
技術	初期HTMLに本文と見出しがある（ソース表示で確認できる）	最優先
禁止事項	隠しテキスト・隠しリンク・キーワードの詰め込みがない	最優先

よくある質問

Q. h1タグは1ページに1つでないとSEO上不利ですか？

直ちに不利になるわけではありません。GoogleのSEOスターターガイドは、見出しの順番はGoogle検索上は問題にならず、理想的な見出しの数もないと説明しています。ただし、h1を1つにしてtitleと内容をそろえると、ページの主題が読者にも検索エンジンにも明確になり、タイトルリンクの意図しない書き換えも防ぎやすくなります。新しく作るなら1つにしておくのが無難です。

Q. W3Cのチェックツールでエラーを0にしないと順位は上がりませんか？

エラーの件数がそのまま順位に影響するわけではありません。Googleは、ウェブの多くは正しいHTMLで書かれていないことを前提にページを処理しています。優先して直すべきは、閉じタグ漏れで本文の範囲が崩れるエラー、head内の要素が本文側に出てしまうエラー、構造化データのエラーです。当サイトのこのページでも2026年10月11日の時点で少なくとも8件のエラーが報告されましたが、そのうち7件は記事本文の外が出どころでした。

Q. meta keywordsタグは設定したほうがよいですか？

Google検索の対策としては不要です。GoogleのSEOスターターガイドは、Google検索はキーワードのメタタグを使用しないと明記しています。設定する時間は、titleやdescription、本文の改善に使うほうが効果的です。

Q. CSSはHTMLに直接書いたほうが表示は速くなりますか？

ファーストビューの描画に必要な最小限のCSS（クリティカルCSS）に限れば、HTMLに直接書くと初期表示は速くなります。一方で、すべてのCSSを各ページに直書きすると修正の手間が増え、ブラウザのキャッシュも効かなくなります。クリティカルCSSだけを直接書き、残りは外部ファイルで管理するのが現実的です。

Q. WordPressを使っていてもSEOコーディングの知識は必要ですか？

必要です。HTMLを直接書かなくても、見出しブロックのレベル選択、リストブロックの使用、画像の代替テキスト、SEOプラグインでのnoindexやcanonicalの設定は、すべてSEOコーディングの判断そのものです。また、テーマやプラグインが出力するHTMLは記事の編集画面からは見えません。当サイトでもプラグインとテーマの構造化データの重複や、本文の出力時に付いた閉じタグはソースを見て初めて見つかりました。

Q. 初心者がSEOコーディングで最初にやるべきことは？

自分のサイトの代表的なページで「ページのソースを表示」を開き、noindexが残っていないか、titleとdescriptionがページ固有か、h1がtitleと対応しているかの3点を確認することです。この3点はインデックスと検索結果の表示に直接関わり、ブラウザだけで数分で確認できます。そのうえで、画像のalt、リンクの書き方、見出しの階層と、本記事のチェックリストの順に進めます。

まとめ

SEOコーディングは、特別なテクニックではありません。head内の指示を正しく書き、本文はタグの意味どおりにマークアップし、公開後は本番のHTMLを確かめる。この3つを、Google検索セントラルの記述に沿って続けることです。「h1は1つ」「エラーは0に」「altにキーワード」といった定説は、公式の説明と照らすと、そのまま守るべきルールではなく「読者のために整える目安」や「やりすぎると逆効果のもの」でした。

優先順位をつけるなら、まずnoindex・title・canonical・viewportといったhead内、次にリンクと画像、そして見出し・構造化データ・表示速度の順です。そして、プラグインやテーマに任せている部分ほど本番のソースを見てください。当サイトでも、構造化データの二重出力と本文の閉じタグのずれは、本番のHTMLを見て初めて見つかりました。タグ単位の詳細はSEO対策に必須のHTMLタグ一覧、コピペ用の雛形はSEO対策済みHTMLテンプレートで確認できます。

本記事は2026年10月11日に調査・執筆しました。仕様は同日にGoogle検索セントラルの公式ドキュメント（SEOスターターガイド、タイトルリンク、スニペット、重複URLの統合、robotsメタタグ、モバイルファーストインデックス、画像SEO、クロール可能なリンク、外部リンクの属性、Core Web Vitals、ページエクスペリエンス、JavaScript SEOの基本、スパムポリシー）の英語版、web.dev（TTFB、Web Vitals、INP）、Google検索セントラルブログ（INPのCore Web Vitals採用）、構造化データの概要、Meta for Developers（共有用画像のドキュメント）、W3C（HTML、W3CとWHATWGの覚書）、Nu Html CheckerのAboutページを開いて確認しています。実測値は、当サイト（scale-basics）が2026年10月11日に本記事URL（書き直す前の本文）で計測したものです。PageSpeed Insightsは同日APIの利用上限により未計測です。なお、当サイトのこの記事自体のGoogle検索での実績は、2026年7月12日〜10月9日の90日間で表示1,649回・クリック4回（旧URL /blog/seo-coding/ を含む）・平均掲載順位20.8位でした。2026年7月21日の前回リライトの前後28日では平均掲載順位が19.2位から20.3位で、順位は改善していませんでした。

無料ダウンロード資料

はじめてのSEO 完全ガイド

Web担当になった人が、90日で自走するための実務書

検索エンジンの仕組みから、キーワード選定・記事づくり・技術対応・効果測定、 そしてAI検索時代の打ち手まで。専門用語の知識ゼロの状態から読み始められるよう、用語はすべて本文中で説明しています。

体裁	PDF／A4縦・全109ページ
収録	図解21点、チェックリスト120項目、90日実行プラン、用語集56語

※フォーム送信後、ご入力のメールアドレス宛にダウンロードリンクをお送りいたします。

資料の詳細と目次を見る

こちらのフォームにご記入ください

入力は1分ほどで終わります。

Website

会社名必須

部署名任意

お名前必須

メールアドレス必須

電話番号必須

従業員規模必須 選択してください 1〜9名 10〜49名 50〜99名 100〜299名 300〜999名 1,000名以上

SEOの検討状況必須 選択してください 何から始めるべきか検討中 自社で運用しているが成果が出ていない 外部への委託を検討している 現在の委託先を見直したい 情報収集のみ

プライバシーポリシーに同意する必須

資料をダウンロードする

ご入力いただいた情報は、資料のご送付および当社サービスのご案内のために利用します。