「とりあえずブログ機能を入れて」の罠：WordPress等を用いたコンテンツSEOを失敗させない要件定義

「自社で情報発信をしてSEOを強化したいから、とりあえずWordPressでブログ機能を入れておいて」

クライアントからのこのありふれた要望に対し、「承知しました。標準の投稿機能を使えるようにしておきますね」と答えてしまう若手Webディレクターは、その時点でプロ失格です。率直に指摘します。「ブログ機能を入れること」と「SEOで成果が出ること」の間には、海よりも深い断絶があります。

単にCMS（コンテンツ管理システム）を導入し、空のテキストエディタをクライアントに渡すだけの行為は、システム導入の丸投げであり、ディレクションではありません。特に生成AIが検索結果を生成するAIO（AI Overviews）時代において、構造化されていない「ただの日記（ブログ）」は、検索エンジンから一切の評価を受けず、完全に透明な存在となります。

本コラムでは、WordPress等のCMSを用いたコンテンツSEOを失敗させないために、プロのディレクターが必ず要件定義で縛る「運用ガバナンス」と「AIO対応の構造設計」の鉄則を解説します。

1. 盲点：自由すぎるエディタが「DOMの崩壊」と「デザインの死」を招く

WordPress等の標準機能であるブロックエディタ（Gutenbergなど）は、直感的に操作できる反面、素人が自由にHTML構造やインラインスタイルをいじれてしまうという「致命的なリスク（脆弱性）」を抱えています。

例えば、白と黒を基調としたスタイリッシュで洗練された「モノトーンのナレッジポータル」を構築したとしましょう。しかし、要件定義でエディタの制限をかけていなければ、公開後数ヶ月でどうなるか。 クライアントの担当者が「ここを目立たせたいから」と、エディタ上でテキストを原色で赤く塗りつぶし、無駄な空白（brタグの連打）を空け、見出しタグ（h2やh3）ではなく文字サイズを強制的に大きくしただけの「疑似見出し」を乱造します。

これは、視覚的なブランドデザインが崩壊するだけでなく、SEO・AIOの観点からは「死」を意味します。 AI（LLM）は画面の見た目ではなく、裏側のHTML（DOMツリー）の意味構造を解析してエンティティを認識します。インラインスタイル（直接的な色やサイズの指定）で汚染され、見出しの階層構造が破綻したページは、AIにとって「解析不能なノイズ」と判定され、検索結果のソースとして引用されることは永遠にありません。

2. 即日実践！CMS導入を「デジタル資産構築」に変える要件定義3つの鉄則

CMSを導入する真の目的は、単なる更新作業の簡略化ではなく、クライアントが持つ専門知識を「機械（AI）が読み取れる構造化データ」として蓄積し、企業の永続的なデジタル資産（ナレッジ）へと変換することです。

これを実現するため、ディレクターは以下の3つを必ず要件定義に組み込んでください。

優先順位1：ブロックエディタの「自由」を奪うガバナンス設計

クライアントに「何でもできるエディタ」を渡してはいけません。ディレクターは、システムの制約によってヒューマンエラーを強制的に防ぐ防波堤を作る必要があります。

• 【実践アクション】 要件定義書において、「使用可能なブロックの制限」と「カラーパレットの固定」を明記します。例えば、サイトのトーン＆マナーに合わせたモノトーンの配色のみを選択可能にし、フォントサイズの直接変更を禁止（CSSクラスでの制御のみ許可）します。 さらに、記事作成のための専用カスタムブロック（例えば「この記事の結論ブロック」「ポイント解説ブロック」など）のコードを事前に定義・開発し、「担当者は決められた枠にテキストを入れるだけで、自動的にセマンティックで美しいHTMLが出力される仕組み」を要件として組み込みます。

優先順位2：「お知らせ」と「ナレッジ」の分離（カスタム投稿タイプの設計）

標準の「投稿（Post）」機能を一つだけ用意し、そこに「夏季休業のお知らせ」と「事業リスクに関する専門的な解説コラム」を混在させるのは最悪の情報設計（IA）です。

• 【実践アクション】 データベースの設計段階で、情報の性質ごとに「カスタム投稿タイプ（Custom Post Type）」を完全に分離してください。 企業のニュースは「お知らせ（news）」として時系列で処理し、SEOの核となる専門コンテンツは「ナレッジ（knowledge）」や「コラム（column）」として独立させます。これにより、ナレッジ側のURL構造（ディレクトリ）をSEOに最適化し、AIO向けに「このディレクトリは専門的な一次情報の集合体である」というシグナルを検索エンジンに明確に伝えることができます。

優先順位3：テンプレート階層とJSON-LD（構造化データ）の自動出力

クライアントに「記事を公開するたびに、SEOの設定画面で構造化データのコードを書いてください」と依頼するのは現実的ではありません。ITの仕組みは、担当者が意識せずともSEO要件を満たすように裏側で完結している必要があります。

• 【実践アクション】 WordPressのテンプレート階層（例えば <?php get_header(); ?> から始まり、コンテンツをループ処理して <?php get_footer(); ?> で閉じる構造）の内部において、「記事が公開された瞬間、自動的にJSON-LD（構造化データ）が生成・出力されるロジック」を開発要件に含めます。 著者情報、公開日、更新日、パンくずリストなどのメタデータを、カスタムフィールドの入力値から自動でパースしてHeadタグ内に出力させることで、AIOに対する情報の「機械可読性」を担保します。

【まとめ：ディレクターは「システム」でクライアントの無知を守れ】

「とりあえずブログを入れておきました。あとは自由に書いてください」 この言葉は、地図もコンパスも持たないクライアントを、AIという未知のアルゴリズムが支配する荒野へ丸腰で放り出すのと同じです。

プロのWebディレクターの仕事とは、ただツールを導入することではありません。 クライアントの貴重な専門知識（ナレッジ）が、誤った操作によってノイズに変わるのを「システムの制約」によって未然に防ぎ、正しいデジタルの道筋へと導くことです。

SEOは、優れたテキストを書くだけでは成立しません。そのテキストを格納し、配信する「CMSの設計とガバナンス」があって初めて機能します。 「ITは知るだけでは終わらない」——この言葉の通り、ツールを知っているだけでなく、それを事業を成長させるための強固な「仕組み」として要件定義に落とし込むこと。今日から、クライアントの要望を鵜呑みにせず、エディタの制限からデータベース設計まで踏み込んだ「プロの要件定義」を実践してください。