WordPressにSEOプラグインは必須ではない｜テーマ側で完結させる設計と向き不向き

WordPressでサイトを作るとき、SEOプラグインを入れるのが当たり前になっている。ただ、入れるかどうかは要件ではなく手段の選択でしかない。プラグインなしでSEO要件を満たしているサイトは実際にあるし、制作会社としてそちらを選んだ案件もある。

先に結論を書く。SEOプラグインは必須ではない。ただし「入れない」を選んでよいのは、テーマを触り続けられる体制がある場合に限る。逆に、更新を自社で回すつもりで、コードを触れる人が社内にも制作会社にもいないなら、素直に入れたほうがいい。

この記事では、SEOプラグインが実際に何を出力しているのかを分解したうえで、テーマ側で完結させる設計と、入れる／入れないの判断基準を書く。判断を間違えると、公開後に構造化データが二重になったり、サイトマップがGoogleに1本も届いていなかったりする。実案件で確認している内容をそのまま出す。

SEOプラグインが担っている仕事は6つしかない

まず、SEOプラグインが実際に何をしているかを分解する。名前が大きいので万能に見えるが、出力しているものは整理すると6種類だ。

項目	何をしているか	プラグイン以外の選択肢
title / meta description	ページごとの個別指定	テーマ側の入力欄（メタボックス）＋10行程度の出力コード
canonical	正規URLの明示	WordPressコアが標準で出力する
OGP / Twitter Card	SNSシェア時の見え方	テーマのwp_headに10行程度
JSON-LD（構造化データ）	検索エンジン向けの意味づけ	テーマ内の専用ファイル1本
sitemap.xml	クロール対象の提示	コア標準の/wp-sitemap.xml
robots（noindex制御）	検索結果に出す／出さないの制御	コアの公開設定＋テーマ側の条件分岐

canonicalとsitemapはWordPressコアが標準で持っている。残る4つも、テーマ側に書けば済む分量だ。「SEOプラグインを入れないとSEOができない」というのは正確ではなく、正しくは「入れると、コードを書かずに管理画面から設定できる」である。

つまり判断の軸はSEOの良し悪しではなく、誰がどこを触るのかという運用の設計になる。ここを取り違えたまま「とりあえず入れる」と、後述する二重出力や設定の分散が起きる。

テーマ側で完結させた実案件の設計

実際にSEOプラグインを入れずに構築した案件がある。地域密着の専門工事業者のコーポレートサイトで、自作のクラシックテーマで作った。構成はこうなっている。

• title / description：投稿・固定ページごとの自前メタボックス（入力欄）
• sitemap：WordPressコア標準のwp-sitemap.xml
• canonical：コアの出力をそのまま使用
• OGP：テーマのwp_headに自前で10行
• JSON-LD：inc/schema.php 1ファイルのみが出力元
• noindex制御：コアの「検索エンジンでの表示」設定を唯一の真実にする

この案件でSEOプラグインを入れなかった理由ははっきりしている。構造化データのValidatorエラーをゼロにして納品するという要件があったからだ。プラグインは独自にschemaを出力するものが多く、テーマ側の自前JSON-LDと同居させると、同じ意味の記述が2つ出る状態になりうる。

ここで「プラグインの設定画面でschema出力をOFFにすればいい」と考えたくなるが、その対処はおすすめしない。設定でOFFにしたものは、プラグインの更新で仕様が変われば復活しうる。納品後に更新が走った時点で要件が崩れる可能性を残すことになる。要件が「常にエラーゼロ」なら、出力しうるものを最初から入れないほうが構造的に確実だ。

出力元を1ファイルに寄せる

この設計で最も効くのが、JSON-LDの出力元をinc/schema.phpの1本に集約したことだ。集約したうえで、他の場所からJSON-LDが出ていないことをgrepで実測して確認している。

出力元が1つに決まっていると、内容を直すときに探す場所が1箇所で済む。構造化データは「どこかにもう1つ書いてあった」が一番やっかいで、これは検索しないと見つからない。出力元を1つに決めて、決めたことを実測で確認する。これはプラグインを入れる場合でも同じで、入れたうえでテーマにも書いてある状態が最悪になる。

更新担当が触る項目は入力欄にする

プラグインを外すなら、クライアントが更新する部分を必ず入力欄にしておく必要がある。この案件では、料金・実績数値・住所や電話番号といった情報をすべて管理画面のフィールドで持たせ、テンプレートへの直書きをゼロにした。同じ値を本文と構造化データの両方に流す設計にしてあるので、料金を1箇所直せば両方が同時に変わる。

構造化データを手打ちの表と別管理にすると、単価改定のときに本文と構造化データが食い違う。値の出どころを1つにしておけば、この食い違いは起こりようがない。

もう一点、公開設定の扱いも重要だ。制作中にnoindexをかけたまま公開してしまう事故は起こりうるので、コアの公開設定を唯一の判断材料にしたうえで、管理画面の通知・管理バー・サイト設定画面の3箇所に警告を出すようにした。設定を1つに絞って、その状態を見えるところに出すのが予防になる。

テーマに書くか、自作プラグインに書くか

自社の新サービスサイトでは、同じことを自作の小さなプラグインで実装した。既製のSEOプラグインは入れず、meta description・OGP・JSON-LD・robots・titleの出力を1本のプラグインにまとめている。

テーマに書くか自作プラグインに書くかの違いは、テーマを変えたときに設定が消えるかどうかだ。デザインを作り直す予定があるならプラグイン側に、テーマとサイトが一体で長く使うならテーマ側に置く。この自社サイトは後からデザインを合わせたテーマに切り替えたが、SEO側は別のプラグインに分けてあったので影響を受けずに済んだ。

入れない／入れるの判断基準

判断は次の3項目で決まる。

SEOプラグインを入れないほうがよい条件

1. 制作側がテーマのコードを触り続けられる（保守契約がある、または社内に触れる人がいる）
2. 構造化データやメタの要件が明確に決まっていて、勝手な出力が混ざると困る
3. 更新担当が触る項目を、入力欄として用意しきれる

SEOプラグインを入れたほうがよい条件

1. 記事数が多く、既存記事のメタを一括で扱う運用がある
2. 外部製のテーマを使っていて、テーマ側が更新で上書きされる
3. コードを触れる人が社内にも制作側にもいない

3番目が実務では一番大きい。入れない設計は、入れる設計より運用の属人性が上がる。ページを1枚足すたびに制作側の作業が発生する構造なら、その体制が続く前提が崩れた時点で困る。逆に、記事を継続的に量産するメディアなら、既存記事のメタを一括で書き換えられる仕組みがあったほうが実務が回る。

実装前に想定しておくリスクと予防

ここからは、どちらを選ぶ場合でも起こりうる問題と、その予防を書く。公開後に気づくと直すコストが上がるものばかりなので、着手前に読んでおくとよい。

「入っている前提」でコードを書かない

自動化スクリプトやAPI連携を書くとき、特定のSEOプラグインが入っている前提でコードを書くと外す。REST APIの応答から値を取り出す処理で、実際には存在しないキーを既定値付きで読むと、空のまま処理が通ってしまい「取れている」ように見える。データベースに使われていないテーブルの残骸が残っていることもあり、これも「入っている」と誤認する材料になる。

予防は単純で、触る前に実際の出力元を特定すること。ページのソースを見て、そのメタ情報がどこから出ているかを追う。記事数の多いメディアサイトを扱ったときは、メタ説明の出力元がSEOプラグインではなくテーマ側の関数で、優先順位が「カスタムフィールド → 記事の抜粋 → 自動生成」の順だった。この順番がわかれば、書き込むべき場所は自動的に決まる。

サイト名を付ける場所は1箇所にする

titleにサイト名を付ける処理は、複数の層で重複しやすい。SEOプラグインのタイトルテンプレートと、フロント側の出力の両方で付けると、検索結果のタイトルにサイト名が2回出る。

自社サイトの点検でこれを実測したところ、全172本中165本で二重になっていた。除去する関数を1つ足して一括で解消したが、これはサイト名を付ける層を1つに決めておけば起きない問題だ。ヘッドレス構成のようにCMSと表示側が分かれている場合は特に、どちらが付けるのかを最初に決めておく。

あわせて、サイト名の長さも見直す価値がある。同じサイトで正式社名を入れていた部分を短い表記に変えたところ、表示幅で112ピクセル、日本語にして8文字ぶんが空いた。ここは記事タイトルに使える枠になる。正式社名は構造化データとog:site_nameに残しておけば情報としては失われない。

サイトマップの場所は構成で変わる

サイトマップのURLは構成によって変わる。コア標準なら/wp-sitemap.xml、SEOプラグインを入れるとプラグイン側のURLに切り替わることが多い。

ここで注意したいのがrobots.txtに書いてあるサイトマップURLが、実際に開けるかどうかだ。構成を変えたあとに記載を直し忘れると、記載されたURLが404のままになる。この状態はサイト自体は正常に見えるので気づきにくいが、Googleにサイトマップが届いていないのと同じことになる。

予防は、構成を変えたら必ずそのURLを開いて確認する。ブラウザで開いて中身が出るか、Search Consoleで送信して正常に読まれるかを見る。プラグインを入れる／外すの前後は必ずこの確認を挟む。

タイトルの文字数は検索結果に出る値で数える

タイトルの長さを点検するとき、記事の見出し（H1）で数えると実態とずれる。SEOプラグインやテーマ側で別のタイトルを設定している場合、検索結果に出るのはそちらだからだ。

自社サイトの点検では、H1基準で数えたときと検索結果に出る値で数えたときで、対象記事数が3倍以上違った。数える対象を間違えると、必要のない作業を大量に積むことになる。文字数ではなく表示幅で判断するのが正確で、全角と半角、英数字の混在で実際の幅は変わる。

記述をmu-pluginsに置かない

SEO関連のコードをmu-pluginsディレクトリに置く方法があるが、これは避けたほうがいい。mu-pluginsは管理画面から無効化できないため、構文エラーがあると画面が真っ白になり、管理画面にも入れなくなる。

通常のプラグインとして置いておけば、致命的なエラーがあってもWordPress側の保護機能が働き、有効化に失敗するだけでサイト本体は無傷で済む。テーマのfunctions.phpに直接書く場合も同じリスクがあるので、変更前のバックアップは必ず取る。

検証はキャッシュを外して行う

サーバー側のキャッシュが効いていると、直したはずの出力が反映されていないように見える。逆に、直っていないのに直ったように見えることもある。

検証のときはURLにタイムスタンプなどのパラメータを付けてキャッシュを回避し、実際に配信されているHTMLを見る。REST API経由で更新した場合も、更新レスポンスの成功だけを見ずに、公開URLを取得し直して反映を確認する。「更新できた」と「表示が変わった」は別の話として扱う。

判断と実装の手順

最後に、実際に進めるときの順番をまとめる。

1. いま何が出ているかを実測する。ページのソースでtitle・description・canonical・OGP・JSON-LDを確認し、それぞれの出力元を特定する
2. 出力元を1つに決める。プラグインを使うならテーマ側の重複を消し、テーマ側で持つならプラグインを外す
3. 更新担当が触る項目を入力欄にする。テンプレート直書きをなくし、値の出どころを1つにする
4. 公開前に確認する。公開設定、サイトマップのURLが開けるか、構造化データがValidatorを通るか、タイトルの表示幅

この順番で進めれば、プラグインを入れる場合も入れない場合も同じ品質に到達できる。逆に言えば、プラグインを入れただけでこの4項目が満たされるわけではない。入れたうえで設定が空のままなら、検索結果に出る文言はGoogleの自動生成に任せることになる。

まとめ

SEOプラグインは必須ではない。出力しているものは6種類で、そのうちcanonicalとsitemapはWordPressコアが標準で持っている。残りもテーマ側に書ける分量だ。

判断の軸はSEOの良し悪しではなく、コードを触れる人がいるか、更新担当が入力欄だけで運用できるかという体制の話になる。触れる人がいて要件が明確なら、入れないほうが出力を管理しやすい。記事量産があり触れる人がいないなら、入れたほうが実務が回る。

どちらを選ぶにしても、出力元を1つに決めることと、公開前に実際の出力を自分の目で確認することは変わらない。ここを省くと、サイトは正常に見えるのに検索側にだけ問題が残るという、一番気づきにくい状態になる。