Last updated on

SEO対策の全体像（WordPress版）— WPテンプレが担う土台と、プラグインに委ねる部分

  • SEO
  • WordPress
  • Web制作
  • コーディング

前編では、SEO対策の種類とコーダーの担当範囲を整理し、静的サイト制作用テンプレート（Vite + EJS）でどこまで土台を入れているかを書いた。

この記事はその続きである。よしあきが案件で使う WordPress 制作用テンプレート（クラシックテーマ + Vite）について、同じ観点で「できていること」と「別の層に任せていること」「これから決めたいこと」を言語化する。ご紹介というより、自分用の棚卸しが主目的である。

制作フロー全体では WordPress サイト制作の手順と、指定が無いときのよしあきルール の「構築」「仕上げ」でも、SEO プラグインや自動生成 URL の扱いに触れている。本記事はその SEO 部分を深掘りした続きである。

前編との関係

SEOはコンテンツ・サイト設計・HTMLとメタ・技術・運用に分かれる。コーダーが中心になりやすいのは、決まった方針を、検索エンジンとユーザーが読める実装に落とす部分だ（詳細は前編）。

静的テンプレでは、pages 設定と共通 _head.ejs、ビルド後 HTML 処理までテーマ側が抱えていた。WordPress では head の中身の多くが wp_head() 経由になり、メタ・OGP・サイトマップなどは SEO プラグインに寄せやすい。テーマは「殻・マークアップ・同梱アセット・編集 UX・意図しない URL の整理」に寄る。

静的テンプレと WP テンプレの責務分担

前編の「コーダーに求められること」と対応させると、おおよそ次のようになる。

領域静的テンプレWP テンプレ典型（プラグイン / WP 本体）
title / descriptionsite.config + _head.ejstitle-tag、固定ページごとの編集欄の調整SEO プラグイン
canonical / OGPテンプレで組み立てwp_head() に委譲（テーマで二重出力しない）同上
見出し・HTML 構造EJSPHP テンプレ + ty_ ヘルパー—
テーマ同梱画像ビルド後の picture / width・height 付与ty_img 等 + ビルド時の寸法 JSON—
投稿・メディア画像（対象外）WP ネイティブ（サイズ・srcset 等）を優先メディアライブラリ
意図しない一覧 URL（静的では発生しにくい）template_redirect で 404 など—
HTML 検証コミット前に dist を検証現状、同等の自動検証は入れていない—
構造化データ案件対応基本はプラグインFAQ 等

「テンプレだけで SEO が完結する」のではなく、テンプレ + プラグイン + 運用の三層で見る必要がある、というのが WordPress 版の前提である。

WP テンプレでテーマ側が担っている土台

head の殻と wp_head()

header.php では charset、viewport、favicon、必要なフォントの preload などをテーマが出し、そのあと wp_head() を呼ぶ。title 本体や description、OGP、canonical は、原則としてここに差し込まれる（SEO プラグインや WP 本体の title-tag）。

テーマの役割は 差し込み口を壊さないことと、テーマ独自のメタをプラグインと二重に出さないことである。

補足すると、title-tag はテーマが add_theme_support('title-tag') で有効化する WordPress 本体のタイトル出力機能である。テーマ側で <title> を直書きせず、ページ種別に応じたタイトル生成を WordPress と SEO プラグインに任せるための土台になる。

title-tag と見出しのルール

add_theme_support('title-tag') により、ページタイトルは WP の仕組みに乗せる。ヘッダーでは、トップのみロゴを h1、下層は motion.div 相当のラッパにする、といった見出しの階層をテンプレ側で守る。

編集画面：本文エディタを必要なページだけに絞る

固定ページのうち、デザイン上「本文エディタを使わない」テンプレでは、クラシック編集に切り替えて editor サポートを外す。本文欄に入力した内容がページ表示へ反映される仕組みにしていたため、使わないページでは「入力できるのに表示が想定と違う」状態を避ける意図がある。必要になったら設定変更しやすいように、「このページでは本文エディタを非表示にしています。（テーマ設定: functions-lib/func-page-editor.php）」のような説明を編集画面に表示する。

テーマ同梱画像（ty_img）

テーマ配下の src/assets/images/** は、ty_img() / ty_picture_img() で出力する。

これは、ロゴ・装飾画像・固定セクション用画像など、WordPress のメディアライブラリを通らないテーマ同梱画像を扱うための仕組みである。画像のパス解決だけでなく、width / height、遅延読み込み、PC/SP の出し分けをテーマ側でそろえ、表示速度や CLS の事故を減らす狙いがある。

  • loading="lazy"（LCP 用は eager 指定可）
  • ビルド時に theme-assets.json へ寸法を書き、可能なら width / height を付与（CLS 抑制）
  • PC/SP の出し分けは ty_picture_img（命名規則で _sp を導出する想定）
  • ビルドパイプラインでは imagemin 系で圧縮

テンプレート側では、たとえば次のように呼び出す。

<?php ty_img('common/logo.svg', 'サイトロゴ', true); ?>
<?php ty_picture_img('top/main-visual.jpg', 'メインビジュアル'); ?>

出力後の HTML は、概念的には次のような形になる。実際のパスや属性は、画像ファイル、ビルド結果、関数の引数によって変わる。alt は説明用の例で、案件では画像の意味に合わせて入れる。

<img src="https://example.com/wp-content/themes/theme-name/assets/images/common/logo.svg" alt="サイトロゴ" width="240" height="80" loading="lazy">

<picture>
  <source media="(max-width: 767px)" srcset="https://example.com/wp-content/themes/theme-name/assets/images/top/main-visual_sp.jpg">
  <img src="https://example.com/wp-content/themes/theme-name/assets/images/top/main-visual.jpg" alt="メインビジュアル" width="1200" height="800" loading="lazy">
</picture>

静的テンプレの after-build.mjs が 全 HTML を走査して picture 化するのに対し、WP 版は PHP 出力時点で属性を付ける形に寄せている。投稿本文に挿す画像は、メディアライブラリ側のサイズ・srcset を優先する方針である。

また、静的テンプレではビルド時に WebP / AVIF などの代替フォーマット生成まで入れているが、WordPress 版のテーマビルドには現状そこまで入れていない。WordPress では、運用中に管理画面からアップロードされる画像が増えていくため、テーマ同梱画像だけをビルドで最適化しても対象が限定される。現状は、画像のフォーマット最適化や圧縮は EWWW Image Optimizer に寄せ、テーマ側は同梱画像の出力属性とパス解決を整える分担にしている。

パフォーマンス寄りのテーマ設定

例として、絵文字用スクリプトの無効化、wp_generator の除去（バージョン情報を head から外す）など。フロントの CSS/JS は開発時 Vite HMR、本番は dist の manifest から enqueue する。

これらは「SEO プラグインの代替」ではないが、余計な head 出力を減らすという意味で技術 SEO の土台に入る。

マークアップ・アクセシビリティ

ナビ・ドロワーへの nav、aria-expanded / aria-hidden など。前編と同様、A11y は SEO そのものではないが、意味のある HTML の土台と重なる。

パンくずリストは、よしあきの運用では All in One SEO に寄せている。パンくずは表示上の導線であると同時に、構造化データにも関係するためである。

専用プラグインの Breadcrumb NavXT にもメリットはある。パンくず専用なので、階層・区切り文字・ラベル・投稿タイプやタクソノミーごとの出し分けを細かく調整しやすい。パンくずの表示仕様をかなり作り込みたい案件では候補になる。

一方で、Breadcrumb NavXT を SEO プラグインと併用すると、HTML 内の microdata / RDFa 系の構造化データと、SEO プラグイン側の JSON-LD が重複しやすい。どちらかに寄せるなら、Google が推奨する JSON-LD にそろえやすく、title、canonical、OGP、schema などと同じプラグインで管理できる All in One SEO 側に任せる方が、責務を分けやすい。

自動生成ページを 404 にする（func-no-auto-generate.php）

WordPress は、投稿・タクソノミー・著者・日付などから テーマを置かなくても URL が自動で生える。サイト設計で「その一覧は公開しない」と決めているのに URL だけ残ると、次のような SEO 上の問題になりうる。

  • 薄い・重複しがちな一覧（著者アーカイブ、タグだけの一覧など）がインデックスされる
  • ナビに載せていない導線なのに、クローラが別経路で到達する
  • Search Console に「意図しない URL」が並ぶ

よしあきの WP テンプレでは、functions-lib/func-no-auto-generate.php で template_redirect の段階に、指定した条件のリクエストを 404 に差し替える。

たとえば、著者アーカイブ、カテゴリー一覧、タグ一覧を公開しないなら、次のようにまとめて 404 にできる。

add_action('template_redirect', function () {
	if (is_author() || is_category() || is_tag()) {
		global $wp_query;
		$wp_query->set_404();
		status_header(404);
		nocache_headers();
	}
});

ファイル先頭のコメントには、案件ごとに足せる条件の例も書いてある。

  • 日付アーカイブ: is_date()
  • 検索結果: is_search()
  • デフォルトの「投稿」単体: is_singular('post') など

コーダーがやることは、「このサイトでは公開しない URL 型」を設計と合わせて列挙し、404 か noindex かを決めることである。404 にすると、その URL は「存在しないページ」として扱われる。noindex は「存在はするがインデックスしない」なので、目的が違う。ナビに載せないだけなら 404、管理用に残すなら noindex、といった切り分けは案件・プラグイン設定とセットで決める。

また、404 テンプレ側の meta description は SEO プラグインでは扱いにくいことがある（過去の案件メモでは、404 用 description を 404.php で出す・noindex にする・リダイレクトする、などの選択肢を検討していた）。自動生成 URL を 404 にする話と、404 ページ自体のメタは別レイヤーの課題として残る。

静的テンプレからの「引き継ぎ／置き換え／やめたこと」

テンプレ移行時の整理を、読者向けに要約すると次のとおりである。

静的テンプレWP テンプレ
EJS → 複数 HTMLPHP テンプレ + WP ループ
site.config.js の pages固定ページ・メニュー・SEO プラグイン
_head.ejs でメタ一式wp_head() + プラグイン
after-build.mjs で全 HTML の picture 化テーマ画像は PHP 出力時、投稿画像は WP 標準
validate:html（dist 対象）未実装（dist は HTML サイトではない）

「静的で自動化していたこと」のうち、そのまま持ってこれないものを、プラグイン・運用・別の検証手段で埋める必要がある、という整理になる。

プラグイン前提にしたときのコーダー仕事

案件では SEO プラグイン（例: All in One SEO 系）を入れることが多い。テーマ単体の話を超えるが、よしあきの現状認識としてメモする。

  • メタ・OGP・canonical・schema はプラグイン出力を正とし、テーマで同種のタグを足さない
  • パンくずプラグインと SEO プラグインで 構造化データが二重になることがある → どちらを正とするかは設計判断
  • FAQ リッチリザルトは、ブロックや schema 出力があっても 表示される保証はない → 本番 HTML とリッチリザルトテストで確認
  • 404 の description / noindex は、プラグインだけでは足りないことがある → テンプレまたはフィルターで補うか、方針を決める

コーダーの残り仕事は、本番 HTML が意図どおりかを見ること（表示ソース、Search Console、PageSpeed、リッチリザルトテスト）。前編の「検証できる状態にする」は、チェック対象が dist から 本番 URL + プラグイン設定 に移る、と理解している。

まだ個別対応が必要なこと

テンプレに土台があっても、案件ごとに決めるものは残る。

  • 各ページの title / description（プラグインのフィールド・抜粋）
  • 本文・見出し・メディアの alt
  • 構造化データの種類と、プラグイン間の重複回避
  • カテゴリー・タグ・著者アーカイブを 404 / noindex / 公開のどれにするか（func-no-auto-generate の条件リスト）
  • 検索結果ページを公開するか
  • リダイレクト、noindex、robots.txt / サイトマップ運用
  • Search Console・Analytics

今後の課題（自分用メモ）

  • HTML 出力の検証を WP で何で代替するか（プラグイン任せの限界）
  • 投稿画像とテーマ同梱画像のルール統一（lazy、寸法、代替フォーマット）
  • SEO プラグインとテーマの責務境界を案件テンプレート化（チェックリスト）
  • robots.txt の扱いをテンプレート標準としてどう持つか。現状はテーマ側に固定の仕組みを入れておらず、WordPress 本体・SEO プラグイン・管理画面設定・サーバー側の実ファイルのどこで管理するかを案件ごとに確認している
  • ステージングの Basic 認証下でのクロール・OGP プレビューの注意
  • functions-lib の取捨選択・統合（移行ログ上の P1）と、SEO 関連ファイルの位置づけの明文化

まとめ

前編の静的テンプレは、ページ情報と head、画像後処理、HTML 検証まで ビルド成果物ベースで SEO の土台を抱えていた。

WordPress 制作用テンプレートでは、マークアップ・同梱アセット・編集 UX・意図しない自動生成 URL の 404 化をテーマが担い、メタ・OGP・サイトマップの多くは wp_head() と SEO プラグインに委ねる形になる。

コーダーの役割は変わらない。決まった方針を壊さず、本番 HTML として確認できる状態にすること。違うのは、チェックポイントが dist 単体から 本番相当の URL + プラグイン設定 + 「公開しない URL 型」の整理へ広がる点である。

よしあきにとっての WordPress 版 SEO 対応は、「テンプレに全部入れる」ではなく、三層を切り分けたうえで、テーマが持つべき線をはっきりさせる作業だと整理できる。

関連記事