REVIEW PORTAL · SEO / AIO（詳細版）

SEO/AIO 改善提案（詳細版・全文）

提案書 v1.3 の全文（既知事実の検証＋O1〜O12）をそのまま通読できる詳細版です。要点だけ把握したい場合はやさしい解説版をご覧ください。

確認ポータルへ戻る ／ やさしい解説版 ／ サイト方針資料

版の経緯（v1.0 → v1.3）

本提案書は、外部から渡された SEO/AIO 指示書をもとに、実コードと Google 公式ドキュメントを照合して作成しました。独立レビューを重ねて改訂しています。

改訂の経緯
版主な内容
v1.0初版。ただしデータ層のマージ構造を見落とし、事実判定に誤りがあった。
v1.1自己レビューで重大な事実誤認（記事数・K4/K8 の判定逆転）を是正。
v1.2Codex CLI 独立レビューで「Google 公式に対する言い過ぎ」を是正（FAQ 偏重・E-E-A-T 直接効果・sitemap=indexed 混同 等）。
v1.3（現行）Claude 独立再考察で、Codex も過去版も見落とした欠落（Core Web Vitals／ドメイン移行リスク／エージェント可読性）を補完。
前提：対象はテスト版サイト（/v48＋統合案 /uni）。効果は断定せず、Google 公式準拠と Search Console 実測を根拠とします。架空の数値・捏造ソースは含みません。

既知事実の検証（指示書の指摘 × 実コード）

指示書の「既知事実」を実コードで照合しました。補助金詳細 9件・記事 20本（基本12＋biz-test由来8）。記事データは articles=[...baseArticles, ...btArticles] で統合され、仮スラッグ b001〜b005 も含めて sitemap に列挙されます。

既知事実の判定
ID指摘判定要点
K2CTA が集約・サービス別詳細が不足概ね正補助金詳細以外は単独 URL なし
K3補助金詳細テンプレが完成形正横展開の母型に使える
K4IT導入補助金の記事が重複正記事3本（it-subsidy-2026 / b001 / digital-ai-subsidy-2026）＋詳細1本
K5著者が「編集部」のみで専門性が弱い正実名監修者・資格・プロフィールが未整備
K6連絡先がプレースホルダ正045-000-0000 / info@example.com が各所に実在
K7問い合わせフォームがデモ正「※このフォームはデモです」表示
K8sitemap に b001〜b005正実在し列挙される（※掲載＝インデックスではない。GSC で確認）
K9canonical が pages.dev正（設計どおり）本番ドメイン確定時に origin 差し替え

補足（新事実）：

  • N1（最重要）：1ドメイン集約「統合案 /uni」が構築済み。2サイト維持か統合かの決定が全提案の前提。
  • N3：biz-test 由来記事（b001 等）は目次・図表つきのリッチ構成で、命名スラッグの一部記事の方が薄い。よって対応は「b001 を消す」ではなく「スラッグ改名（301）＋薄い記事の充実」。

O1 現状評価

技術 SEO の土台（canonical/OGP/JSON-LD のベイク、sitemap、noindex 制御、セキュリティヘッダ）は実装済みで水準は高い。主な弱点は次のとおり。

現状の弱点
弱点重要度
E-E-A-T の実体（実名監修者・出典・最終確認日・実連絡先）が未整備。プレースホルダ／デモが信頼を毀損critical
同一制度（IT導入補助金）の記事重複・カニバリ、薄い記事の混在critical
サービス（AI/DX/経営/自治体）に単独 URL・CTA 分岐がないcritical
2サイトか統合かの IA が未確定critical
意味のない仮スラッグ b001〜b005 が sitemap に列挙high
ページ体験 / Core Web Vitals が未測定・未最適化（フォント多ウェイトのレンダーブロッキング読込）high

O2 戦略提言

主要提言
ID提言優先
S1サイトモデルを決定（フェーズ0）。集約（統合案 /uni を正）が有力候補だが、GSC・被リンク・流入・CV を判断材料に揃えてから最終決定。決め打ちしないcritical
S2補助金詳細テンプレ（it-introduction）を中核ハブにし、サービス LP（AI/DX/経営/自治体）の母型へ横展開critical
S3信頼性（E-E-A-T 観点）の実体整備：実連絡先・出典・最終確認日、author は実体に合わせ Organization/Person、YMYL は実名監修者を reviewedBy に。E-E-A-T は順位への直接効果は断定しないが信頼性として重要critical
S4記事の重複整理とスラッグ改名（IT導入補助金の主従設計、b001〜b005 の記述的改名＋301、薄い記事の充実）high
S5質問解決型ページを優先テーマから整備（本数ありきにしない。一次情報・実測クエリ・営業FAQ 基準）high

O3 情報設計（IA）再設計

推奨モデル「統合案 /uni を正」を前提とした構成（2サイト維持なら読み替え）。

統合モデルの IA
階層役割URL 例
トップブランド＋検索＋事業俯瞰/（現 /uni）
サービスハブ5領域/services/{ai,dx,subsidy,management,gov}
補助金（YMYL中核）一覧→詳細9件/subsidy, /subsidy/:slug
メディア質問解決＋事例（記述的スラッグへ統一）/media, /media/:slug
信頼（E-E-A-T）会社情報・監修者・編集ポリシー/about, /about/team/:id, /policy/editorial
CV課題別・補助金別の件名付き問い合わせ/contact

O4 コンテンツ計画

重複の整理

  • IT導入補助金：制度定義は詳細ページ /subsidy/it-introduction に一本化。記事は「最新ニュース」「対象ITツールの範囲」「申請ノウハウ・事例」と意図別に分け、各記事から詳細へ内部リンク。
  • 持続化補助金：詳細を正規に、4記事を「入門／事例／交付申請／実績報告」と段階別に役割分担。

仮スラッグの改名（旧→新・301）

スラッグ改名マップ
旧新（記述的）テーマ
b001it-subsidy-tool-scopeIT導入補助金 対象ITツールの範囲
b002major-subsidies-comparison代表的5大補助金 比較
b003subsidy-vs-grant補助金と助成金の違い
b004monozukuri-vs-shoryokukaものづくり vs 省力化投資
b005jizokuka-basics持続化補助金とは（入門）

質問解決型ページ（優先テーマ候補）

本数ありきにせず、ユーザー課題・実測クエリ・営業 FAQ に基づいて作成。各ページは冒頭に直接回答（結論先出し）＋一次情報の出典リンク＋（表示する FAQ がある場合のみ FAQ）＋関連内部リンク。AI 専用に書き分けるテキストは作りません（Google 公式：AI 機能に特別な最適化は不要）。

  • IT導入補助金は2026年にいくら・何に使える？
  • 持続化補助金とIT導入補助金はどちらを使うべき？
  • 補助金の対象経費にならないものは？
  • 補助金は後払い？入金までの流れと資金繰り
  • 生成AIの社内導入、最初に決める情報管理ルールは？ ほか

O5 ページテンプレート

サービス LP テンプレート（補助金詳細を母型に）

ヒーロー（H1＝検索意図＋価値）→ 対象 → 提供内容（Service の根拠）→ 比較表 → 進め方 → 関連補助金リンク →（表示 FAQ があれば）FAQ → 監修者・最終確認日 → 課題別の件名付き CTA。

性能（Core Web Vitals）の作り込み：画像に width/height（または aspect-ratio）を付けて CLS を防ぎ、ヒーロー画像は LCP 候補として最適化。フォントはウェイトを絞りサブセット化（必要なら読込方法を見直し）。完了目安：主要テンプレで PageSpeed Insights の CWV が「良好」域、または現状からの改善が確認できる。

O6 構造化データ方針

ページ種別ごとの構造化データ
ページ付与する型
トップOrganization（@id を一意化）／WebSite（任意）
会社情報LocalBusiness（実値・プレースホルダ撤去）
サービス LPService＋BreadcrumbList（表示 FAQ があれば FAQPage）
補助金詳細Article/WebPage＋BreadcrumbList（表示 FAQ があれば FAQPage）。金額・要件は一次情報リンク必須
記事Article＋BreadcrumbList。author は実体整合（Organization/Person）、YMYL は reviewedBy に実名監修者。dateModified は記事個別の最終確認日
監修者Person（実名・jobTitle・worksFor・sameAs）

マークアップは可視コンテンツと一致。FAQPage は表示している QA のみ（FAQ リッチリザルトは主に政府・健康系の権威サイトに限定）。AI 機能向けの特別な構造化データは不要。

エージェント可読性（AI が読みやすい構造）：意味的な HTML（見出し階層・landmark・適切な表/リスト）、a要素＋href の素直なリンク、label/autocomplete を備えた機械可読な問い合わせフォーム。URL の可読性だけでなく、構造全体で AI と人の双方が把握・操作しやすくします。

O7 内部リンク設計

  • ハブ：補助金一覧 /subsidy（最重要）／補助金支援 LP /services/subsidy／記事一覧 /media。
  • スポーク：各記事は対応する補助金詳細・サービス LP へ文脈リンク。詳細ページ末尾は関連記事・関連補助金へ。
  • 全リンクは a要素＋href。アンカーテキストは内容を表す具体語。孤立ページ（被リンク0）を解消。

O8 コンバージョン導線

現状は CTA が #support/#contact に集約、フォームはデモ、分岐なし。

  • 相談 CTA を 3〜4分岐に（補助金／AI・DX導入／経営・その他（＋自治体））。過分割は避ける。
  • 各詳細・LP から件名（制度名・サービス名）を contact にプリフィル。
  • フォーム本番化：実送信先接続・スパム対策（CSRF/Turnstile）に加え、プライバシーポリシー導線・同意チェック・送信ログ・通知失敗時のフォールバックを用意。

O9 ロードマップ

短期・中期・長期
時期主な施策
短期（0-1か月）サイトモデル確定／プレースホルダ撤去・フォーム本番化／監修者の実体化・編集ポリシー／仮スラッグ改名＋301・本番 origin 差し替え準備／記事 dateModified 個別化＋最終確認日の可視化
中期（1-3か月）記事重複の整理＋内部リンク・薄い記事の充実／サービス LP 4本＋Service／質問解決ページ（優先テーマ）／Core Web Vitals 測定→フォント・画像最適化／【移行する場合】事前ベースライン→301マップ→GSC アドレス変更→移行後監視
長期（3-6か月）業種別 LP・事例拡充（許諾済みのみ）／Search Console 実測に基づく改稿サイクル定着・CWV 継続監視

O10 KPI 設計

3層 KPI
層見る指標（頻度）
SEO（月次）対象クエリの表示回数・平均掲載順位・CTR、インデックス済みページ数、主要ページの獲得クエリ数、カニバリ解消の確認
AIO（月次/四半期）AI 回答での参照の有無（手動サンプリング。確定計測 API がないため定性把握中心）、質問解決ページの表示・CTR
CV（月次）分岐別の問い合わせ件数、フォーム到達率・完了率、CTA→/contact の経路別内訳

目標値は実測ベースライン取得後に設定（現時点で架空の数値目標は置かない）。

O11 リスクと緩和策

主要リスク
リスク緩和策
本番ドメイン未確定のまま canonical/sitemap が pages.dev を指し誤インデックス確定後に origin 一括差し替え。確定まで noindex 運用も検討
プレースホルダ／デモ残置で信頼と問い合わせを毀損短期で撤去・本番化。公開前チェックに「example.com/000-0000 が0件」
スラッグ改名・統合での 301 漏れ・評価リセット旧→新の 301 マップ、sitemap・内部リンク同時更新、段階実施＋GSC 監視
ドメイン移行時の一時的な順位変動・移行ロス事前にベースライン取得→1:1 の 301→GSC アドレス変更→数週間の監視と修正
施策効果の過大断定（成果保証に見える）公式準拠を前提化し、効果は断定せず実測と一次情報を根拠に
未最適化のフォント・画像で CWV 悪化ウェイト削減・サブセット化、画像の寸法指定、CWV 定期測定

O12 ユーザーへの確認事項

先に決めてほしいこと
#確認事項重要度
OQ1サイトを1ドメインに集約してよいか（既存 biz.com の SEO 資産量も判断材料）critical
OQ2本番カスタムドメインは何か（biz.com 継続／kashinoya.co.jp／新規）critical
OQ3監修者の実名・資格・外部プロフィール URL を公開してよいかhigh
OQ4実連絡先（電話・メール・住所・営業時間）の公開可否と実値high
OQ5問い合わせの実送信先とスパム対策方針high
OQ6-8サービス LP の優先公開順／旧 URL の被リンク状況／事例の掲載許諾範囲medium