WordPressのSEOを自作するメリット・デメリット|AIOSEO・Yoastを使わない選択肢


WordPressのSEO自作とは、AIOSEOやYoast SEOなどのSEOプラグインを使わず、テーマファイル(functions.php / header.php)にSEO機能を直接実装する方法です。プラグイン肥大化を避けたい個人開発サイト・中規模以下の自社メディアでは有効ですが、編集者が複数いるクライアントサイトには向きません。

この記事では、AIOSEOを使わずにWordPressテーマでSEOを自作する判断基準・メリット・デメリット・必須実装要素を、当サイトCodeQuest.workでの運用経験を元に解説します。「プラグインを減らしたいが何を実装すれば代替できるのか」が分かる構成です。


WordPressのSEO自作とは(定義と前提)

SEO自作とは、SEOプラグイン(AIOSEO / Yoast SEO / Rank Math 等)を使わず、テーマ側でSEO機能を実装する運用形態を指します。具体的にはfunctions.phpやテーマ内 inc/seo/ といったディレクトリにPHPコードを記述し、title・meta description・OGP・構造化データ・canonical・sitemap などをすべて自前で出力します。

前提として、WordPressコア自体にもSEOに関する出力機能(wp_head()からのtitle出力、サイトマップ機能など)が一部備わっています。自作SEOとは「コア機能で足りない部分をテーマ側で補完する」アプローチで、プラグインで補う方法と並列の選択肢です。

向いているサイト:個人開発の技術ブログ、自社運営の中規模以下メディア、テーマ開発を業務にしている制作会社の自社サイト。

向いていないサイト:編集者が複数いるクライアントサイト、SEO担当者が非エンジニアの企業サイト、テーマを頻繁に切り替える可能性があるサイト。


SEOを自作するメリット5つ

AIOSEOを含む主要SEOプラグインは多機能ですが、その代償としてPHP実行負荷・DB書き込み・管理画面の重さが発生します。自作SEOで得られる主なメリットは以下の5つです。

① ページ表示速度の改善(PHP/DB負荷ゼロ)

AIOSEOは多くのフィルターフックを介してtitle・meta・構造化データ・OGPを動的生成します。これに伴うPHP関数呼び出しとDB問い合わせは、特に低スペックサーバーで体感差が出ます。自作実装では「必要な処理だけ」をテーマ側に書くため、無駄な処理が発生しません。Core Web Vitals(特にLCP・INP)の改善余地が大きくなります。

② 実装の完全コントロール

プラグインの出力は仕様変更や設定UIの制約に縛られます。「この投稿タイプだけ別のcanonicalを出したい」「特定カテゴリだけnoindexにしたい」といった細かい要件は、プラグイン側の対応待ちになることがあります。自作なら全ての分岐・出力タイミングを自分で設計でき、サイト固有の運用要件に正確に合わせられます。

③ 不要機能の排除でDB肥大化を防ぐ

SEOプラグインは「リダイレクト管理」「ローカルSEO」「ソーシャル統計」など、SEOの周辺機能を多く搭載しています。使わない機能でもDB(wp_optionsやpostmeta)に設定値・キャッシュが蓄積されることがあり、サイト規模が大きくなるほどデータベース肥大化の原因になります。自作なら必要な機能だけを実装するため、postmetaに残るのは自サイトで設計したキーだけです。

④ プラグインアップデート依存からの解放

SEOプラグインは更新頻度が高く、メジャーアップデートで設定画面の構造やフィルターフック名が変わることもあります。プラグイン側のバグで一時的に構造化データが壊れる事例も過去にありました。自作なら、自分が触らない限り出力は変わりません。Googleの仕様変更にはこちらから能動的に追従する必要がありますが、突然の挙動変化に振り回されることはなくなります。

⑤ E-E-A-T強化と技術力アップ

SEOプラグインに任せていると、構造化データ・canonical・OGPの仕様を意識せずに済みます。逆に自作すると、schema.orgのプロパティ設計・正規URLの判定ロジック・FAQの抽出条件などを自分で理解する必要が出てきます。この知識は AI検索時代のSEO対策 で求められるE-E-A-T発信や、クライアント案件での提案力に直結します。


SEOを自作するデメリット5つ

メリットの裏返しがそのままデメリットになります。「自作で得られる自由度」と「自作で背負う責任」のトレードオフを正しく理解して判断する必要があります。

① 初期実装工数が大きい

SEOプラグインなら数分でインストール&基本設定が完了しますが、自作はゼロから設計が必要です。title・meta description・OGP・構造化データ・canonical・hreflang・sitemap など、後述する 必須実装要素6点 を一通り組むだけで、慣れた開発者でも実働数日〜1週間ほどかかります。「明日リリースしたい」サイトには向きません。

② Googleの仕様変更への追随責任

schema.orgのプロパティ追加・Google検索の構造化データ要件変更・OGPの最適仕様変化などに、自分で追従する必要があります。プラグインなら自動アップデートで対応されますが、自作はGoogle検索セントラルやSchema.orgの更新を定期的にウォッチして、自分のコードに反映する手間が発生します。

③ 編集者向けの管理画面UIがない

AIOSEOやYoastは投稿編集画面に専用UIを表示し、SEOタイトル・メタディスクリプション・キーワード・読みやすさスコアなどを編集者が直感的に操作できます。自作の場合、最低限「投稿編集画面にSEOタイトル/メタディスクリプション入力欄」をメタボックスで追加する実装は必要で、これを省くと編集者が触れなくなります。コーディングに不慣れなライターが在籍するサイトでは負担が大きくなります。

④ バグ・脆弱性のリスクを自分で負う

主要SEOプラグインは数百万サイトで使われており、バグが見つかれば速やかに修正されます。自作コードは自分しか見ないため、エスケープ漏れ・XSS・出力タイミングミスなどの問題が長期間気付かれない可能性があります。出力するHTMLには esc_html() esc_url() esc_attr() などWordPressのエスケープ関数を必ず通すなど、セキュリティ意識を持って実装する必要があります。

⑤ 移行・引き継ぎコスト

SEO自作はテーマに依存します。テーマを切り替えた瞬間にすべてのSEO設定が失われるため、サイトをリニューアルする際は実装の移行が必要です。また、後任の開発者にサイトを引き継ぐ場合、独自実装のドキュメント化が必須になります。プラグインなら「AIOSEOで管理しています」の一言で済む引き継ぎが、自作だと数ページのドキュメントになる可能性があります。


自作 vs プラグインの判断フローチャート

メリット・デメリットを踏まえて、自作 / プラグイン / ハイブリッドの3択を判断する基準を整理します。以下の表で当てはまる項目が多い方を選択してください。

判断軸自作向きプラグイン向き
開発リソーステーマ開発できるエンジニアがいるエンジニア不在 or 別案件で多忙
サイト規模個人 or 小規模(〜数百記事)大規模(数千〜数万記事)
編集者の人数運営者本人のみ複数の非エンジニアライターがいる
SEO理解度schema.org・canonical等を理解SEOは外注 or プラグイン任せ
サイトの寿命長期運用予定(5年以上)短期キャンペーン or 改修頻繁
テーマ変更予定自作テーマで長期運用市販テーマ切り替えの可能性あり
パフォーマンス重視度Core Web Vitals最優先機能性・UI優先

「自作向き」が4つ以上当てはまれば自作を検討する価値があります。3つ以下ならプラグイン継続、判断に迷うなら後述するハイブリッド戦略がおすすめです。


自作SEOで必須となる実装要素6点

AIOSEOを置き換えるには、最低限以下の6要素を自作で実装する必要があります。これらが揃わないとSEOプラグインから乗り換えた瞬間に検索順位が下がるリスクがあります。実装着手前に必ずチェックしてください。

① title / meta description の管理機能

投稿ごとにSEOタイトルとメタディスクリプションを編集できる仕組みが必要です。実装方針としては、postmetaにカスタムフィールド(例:_seo_title / _meta_description)を持たせ、投稿編集画面にメタボックスで入力欄を追加します。wp_headフックで出力する際、postmetaが空の場合は投稿タイトルやexcerptをフォールバックとして使う設計が一般的です。詳しくは meta descriptionの書き方ガイド を参照してください。

② OGP / Twitter Card

SNSシェア時のプレビュー表示に必須のメタタグです。og:title / og:description / og:image / og:url / og:type と、twitter:card / twitter:image あたりを wp_head で出力します。アイキャッチ画像が設定されていない投稿のフォールバック画像も用意しておく必要があります。実装後は OGPプレビューツール で表示確認するのがおすすめです。

③ 構造化データ(JSON-LD)

Google検索のリッチリザルト・AI検索エンジンの引用元判定に大きく影響する要素です。最低限実装すべきは Article(個別投稿)、BreadcrumbList(パンくず)、Organization(運営者情報)、WebSite(サイト全体)。FAQを使う記事には FAQPage も必要です。Schema.orgの仕様に正確に従う必要があり、自作では @graph 形式で複数スキーマを統合する設計が推奨されます。詳しくは AI検索時代のSEO対策入門 で解説しています。

④ canonical / hreflang

canonical URLは重複コンテンツ対策の必須要素です。WordPress標準でも一部出力されますが、ページネーション・タグページ・パラメータ付きURLでの挙動を自分でコントロールする必要があります。多言語サイトを運営する場合は hreflang(ja / en / x-default)も必要です。rel属性に関する周辺知識は nofollow・dofollow・noreferrerの違い で整理しています。

⑤ robots / noindex 制御

投稿単位・カテゴリ単位・タグ単位でnoindexを制御する仕組みが必要です。Uncategorizedカテゴリ・薄いタグページ・サンクスページなどはnoindexにすべきケースが多くあります。WordPressの wp_robotsフィルタや robots_meta_value あたりを利用して、条件分岐で出し分けます。当サイトでは最近、Uncategorizedカテゴリにnoindexを追加して カニバリゼーション の予防策を取りました。

⑥ XMLサイトマップ / robots.txt

WordPress 5.5以降はコア機能で /wp-sitemap.xml が自動生成されるため、これをそのまま使う選択肢があります。ただしコアのサイトマップは出力する投稿タイプ・priority・lastmod を細かく制御しづらいため、AIOSEOの「Sitemaps」機能を完全置換するには自前生成が必要になるケースもあります。robots.txt はテーマ側ではなくサーバールートに配置するのが基本ですが、WordPressの仮想robots.txt(robots_txtフィルタ)を使う方法もあります。


実装例:CodeQuest.workの構成

当サイト CodeQuest.work は、上記6要素をすべてテーマ側に実装し、AIOSEO等のSEOプラグインを使わずに運用しています。具体的なディレクトリ構成(概念)は以下の通りです。

themes/codequest/
├── inc/
│   └── seo/
│       ├── title.php          ← SEOタイトル出力
│       ├── meta.php           ← meta description出力
│       ├── ogp.php            ← OGP / Twitter Card
│       ├── structured-data.php ← JSON-LD(@graph統合)
│       ├── canonical.php      ← canonical / hreflang
│       └── robots.php         ← noindex制御
├── functions.php              ← inc/seo/配下を読み込み
└── header.php                 ← wp_head() で出力

カスタムフィールドは _cq_seo_title(SEOタイトル)と _cq_meta_description(メタディスクリプション)を投稿ごとに持たせ、カテゴリ・タグにも termmeta として同等のフィールドを追加しています。各投稿の編集画面にはメタボックスでこれらを編集できるUIを実装しています。

各ファイルの実装コードについて:各ファイルの具体的なPHPコードは、サイト固有の運用要件に応じてカスタマイズが必要なため本記事では公開していません。診断ツール「CodeQuest.work SEO」の有料プランで、当サイトと同等の構成を実装するためのテンプレートコードを提供しています。


ハイブリッド戦略:診断はプラグイン+実装は自作

「自作派」と「プラグイン派」の中間として、実装は自作・診断はプラグインというハイブリッド戦略があります。SEO設定の出力は軽量な自作コードに任せつつ、設定漏れや構造化データのエラー検出は専用ツールで定期チェックする組み合わせです。

当サイトでは、運用フェーズで以下の役割分担を行っています。

役割使用ツール頻度
SEO出力(title・meta・OGP・JSON-LD)テーマ自作(inc/seo/)常時稼働
サイト全体のSEO診断ORECTIC SEO CHECKプラグイン月1回
個別ページのSEOスコア確認CodeQuest.work SEO記事公開ごと
構造化データのバリデーションGoogle リッチリザルトテスト記事公開ごと
パフォーマンス計測PageSpeed Insights月1回

診断専用プラグインは出力に関与しないため、フロント側のパフォーマンスには影響しません。WordPressプラグインでSEO診断する方法SEOチェックツール比較 で診断ツールの選び方を解説しています。


よくある質問(FAQ)

Q. SEOプラグインを完全に置き換えられる?

必須実装要素6点をすべて自作で組めば、AIOSEOの基本機能は置き換え可能です。ただしリダイレクト管理・ローカルSEO設定・SEO健全性スコア表示・ソーシャル統計などの「SEO周辺機能」は自作だと別途実装が必要なため、これらを多用しているサイトは完全置換が難しくなります。基本的なSEOメタ出力に絞れば置き換えやすい、と考えてください。

Q. 自作実装の保守は大変?

初期実装が済めば、日常的な保守は少なめです。実際の負担は「Googleの仕様変更追従(年数回)」と「サイト構造変更時の出し分けロジック修正」が中心になります。WordPress本体やPHPのアップデート時にエラーが出ないか、テスト環境で確認する習慣を持っておけば運用上の問題は起きにくいです。

Q. パフォーマンス改善はどれくらい?

サーバースペック・他プラグインの構成・ページの内容によって変動するため、一律の数値は出せません。Googleが公開している JavaScriptとPHP処理の最適化ガイドライン でも、機能未使用のスクリプトはバンドルから除外することが推奨されています。実測する場合は、AIOSEOアンインストール前後で PageSpeed Insights を計測比較してください。

Q. AIOSEOからの移行手順は?

大まかな移行手順は以下です。①ステージング環境で自作実装を完成させる。②AIOSEOのpostmeta(_aioseo_title など)から、自作のpostmetaキーへデータをWP-CLIまたはSQLで移行する。③本番でAIOSEOを停止し、自作出力に切り替える。④Search Consoleで構造化データ・URL検査でエラーがないか確認する。⑤問題なければAIOSEOをアンインストール。重要なのは「データ移行」ステップを忘れないことです。

Q. クライアントサイトでも自作すべき?

基本的にはおすすめしません。理由は引き継ぎ問題と、クライアント側でテーマを変更した瞬間に全SEO設定が消えるリスクがあるためです。クライアント案件で自作するなら、最低限ドキュメントを残し、移行手順も納品物に含める必要があります。クライアント案件ではAIOSEOやYoastの導入+細かい部分の調整を関数化、という構成が現実的です。


まとめ:自作が向く人・プラグインが向く人

WordPressのSEOを自作するかプラグインを使うかは、開発リソース・サイト規模・編集者構成・運用期間で判断します。本記事で解説した判断軸とトレードオフを整理すると以下のようになります。

  • 自作が向く人:個人開発の技術ブログ運営者、自社サイトを長期運用するエンジニア、Core Web Vitalsを最優先したい開発者、SEO周辺技術を学びたい人
  • プラグインが向く人:非エンジニアの編集者が複数いるサイト、SEO担当者がコード触らない組織、テーマ切り替え可能性があるサイト、短期キャンペーンサイト
  • ハイブリッドが向く人:自作の自由度は欲しいが診断機能も活用したい人、移行リスクを避けつつパフォーマンスを改善したい人

自作SEOを実装するなら、本記事の「必須実装要素6点」のチェックリストを使って漏れなく組んでください。実装後の診断には診断専用プラグインや当サイトのSEOチェッカーをご活用ください。


関連記事