← プロジェクトトップ認証パートナー テクニカルSEO監査
Technical SEO Audit — Independent Fact-Check

認証パートナー
テクニカルSEO監査レポート

全6,061URL実測クロール / 独立ファクトチェック済み

実施日 2026年7月10日 / 対象 https://ninsho-partner.com/ 全ページ
クロールしたURL
6,061URL
サンプリングなし・全数実測
指摘件数
36
A〜E・G・T・M / 追加検証で+12件
サイトマップから脱落しているURL
2,360URL
404を返すサイトマップに収録
ソフト404
93
200を返すが中身はエラーページ
構造化データを持たないページ
5,001ページ
JSON-LD・Microdataとも無し
独立検証で撤回・修正した主張
10
58主張中・全件記述を訂正済み
エリアLPのゼロクリック率
96.2%
4,260本中4,096本・16か月
GSCで確認したサーバーエラー
0
M-1はクローズ

エグゼクティブサマリー

まずここだけ読めば判断できます。全6,061URLの実測とGSC実データに基づく詳細な監査記録です。全文は長いため、意思決定に必要な要点をこの1枚にまとめました。各項目から詳細へジャンプできます。

まず、土台はしっかりしています。常時SSL化(HTTPS)・HTTP/2・Brotli圧縮・パンくずリストの実装・主要検索エンジンとAIクローラーの受け入れなど、サイトの基盤は堅実に整っています(→ 良好な点)。以下は、その土台の上でさらに成果を伸ばすための改善提案です。

3行の要旨

  1. 検索エンジンにはしっかり読まれています。その上で、成果につながる手前でいくつか取りこぼしが起きています。特に、サイトマップの一部がGoogleに届いていないこと、広告の効果測定に重複が生じていること、資料ダウンロードへの導線の一部が切れていることの3点が、優先して手を入れる価値のある箇所です。
  2. エリアLP(都道府県×市区町村のページ)4,260本は、直近16か月で96.2%が検索から1クリックも得ていません。一方でサイトのクリックの92.6%はコラム記事が生んでいます。ページ数を追うより、成果を出している資産に力を集めたほうが効率的、という実データが得られています。
  3. やるべきことには明確な順番があります。まず「計測を正しく整える」数点(2週間以内が目安)を済ませれば、そこからはコンテンツ制作に進んで問題ありません。すべてを一度に行う必要はなく、力の入れどころを絞れます。

まず着手をおすすめする10件(優先度順)

#どこを改善するか期待できる効果・背景時期の目安主な担当
1A-4 問い合わせフォームのHTMLを整える個人情報を入力する画面がモバイルで正しく表示されるようになる。SEO以前に、品質・信頼性に直結する早めに社内エンジニア/制作
2A-1A-3 サイトマップをGoogleに正しく届ける現在2,360ページが発見・更新通知の対象から外れている。あわせて noindex の指定も正しく反映されるようになる2週間社内エンジニア
3T-1 広告のコンバージョン計測の重複を解消するMeta広告で申込みが二重に数えられている状態を正す。広告費の判断精度が上がる2週間広告・計測担当
4B-1 canonicalの設定を見直す固定ページで、任意のパラメータ付きURLが重複ページとして扱われうる状態を解消。修正はテンプレート1箇所で済む2週間社内エンジニア
5G-1 資料ダウンロードへのリンク切れを修正する17ページで資料DLへの導線が404になっている。上位表示された記事からのリード獲得を取り戻せる早めに制作/編集
6A-2 廃止済みページの返し方を整える中身のないページが200を返している状態を整理。FAQは一覧に残るため影響は小、スタッフ紹介27件は復元要否を判断2週間社内エンジニア
7T-2 トップページの計測タグを統一するトップだけ別のGA4・広告アカウントが動いており、データが分かれている状態を一本化する2週間広告・計測担当
8C-1 構造化データを主要ページにも実装する現在はコラム記事のみ。AI検索(AI Overviews等)やリッチリザルトでの露出、企業情報の認識につながる中期社内エンジニア
9G-6T-7 CVフォームのモバイル・アクセシビリティを改善する電話欄で数字キーパッドが出るようにする等、入力のしやすさを高めてフォーム完了率を上げる中期社内エンジニア/制作
10§6 エリアLP 4,260本の方針を決める96.2%がゼロクリック。残す/統合/noindexを層別に判断する。事業側へのヒアリング2問が最後の判断材料判断を先に3AC+ディレクション

全36件の早見表(重大度 × 対応時期)

重大度早めに2週間以内中期(並走可)情報待ち/優先度低
A 評価・クロールへの影響A-4A-1A-2A-3A-5(→ エリアLPの評価 判定待ち)
B インデックス品質B-1B-2B-3B-4B-6B-7B-5(優先度低)
C 構造化データC-1C-2
D セキュリティ・情報管理D-1D-2D-3D-4
E 表示速度E-1E-2E-3(影響小)
T 計測タグT-1T-2T-3T-4T-6T-7
G CV導線G-1G-2G-4G-5G-6G-3(A-4と同時)
M 監視M-1(対応不要)
表の読み方: 「早めに」=品質・情報管理として先に着手したいもの。「2週間以内」=ここまで整えば計測が信頼でき、コンテンツ制作に進んでよい目安(→ 対応計画)。「中期」=コンテンツ制作と並走。「情報待ち」=事業側の判断やヒアリングが先。

この先の詳細を読むとよいのは、各指摘の根拠・実測値・修正手順を確認したい担当者の方です。方針の判断だけであれば、この1枚と「対応計画」の節で足ります。

この監査が見ている観点

テクニカルSEOは「Googlebotがページを読み取れるか」だけの話ではない。本監査は、検索エンジンとAIがコンテンツにたどり着き、理解し、価値を認め、そして訪れた人が行動するまでを一連の経路として捉え、各段でのつまずきを洗い出している。

検索エンジンから見た3つの段

問い該当する指摘の例
クロールできるか(到達)Googlebotがページに到達し取得できるかサイトマップ404(A-1)/リンク切れ(G-1)/リダイレクト(B-4)
理解できるか(解釈)取得した内容を正しく解釈できるか構造化データ(C-1)/canonical(B-1)/見出し階層(B-6)/レンダリング後DOM
価値を認めるか(評価)インデックスして検索結果に出す価値があるか重複・薄いコンテンツ(エリアLPの評価)/クロール済み-インデックス未登録
今回の監査で最も影響が大きい発見は、実は③の段にある。エリアLP 4,260本の96.2%が検索で1クリックも得ておらず、Googleは「読み取った上で、検索結果に出す価値なし」と判断している(GSC実データ検証)。①②が完璧でも③で価値が無ければ検索には出ない。「読み取れるか」で止まらず「出す価値があるか」まで見るのが本監査の主眼である。

いまの時代ならではの2つの観点

従来の①②③(Googlebot向け)に加えて、2026年時点では次の2軸が事業成果に直結する。

観点問い該当する指摘の例
AI AI・LLMに引用されるかAI Overviews / ChatGPT / Perplexity 等が回答の根拠として引用するか構造化データ(C-1)/Organization・WebSiteエンティティの欠落
CV 訪れた人が行動するか(CV)検索から来た人が問い合わせ・資料DL・申込みに至るかMeta Pixelの二重計測(T-1)/リード資料リンクの404(G-1)/CVフォームの実装(G-6・T-7)

「検索で読み取れる」ことと「事業の成果につながる」ことは別である。Meta Pixel が二重発火していれば広告の効果測定が壊れ、リード資料へのリンクが404なら、上位表示されても資料DLというCVを取りこぼす。本監査はこの「読み取れても成果にならない」層まで踏み込んでいる。

00

監査の前提と制約

すべての指摘は下記条件での実測に基づく。複数回調査を行い、再現確認を行った。

項目内容
最終取得日時2026-07-10(日本時間)
取得元日本国内のIPアドレス
ブラウジングツールChrome 131(デスクトップ)/Googlebot/bingbot/各AIクローラで差分確認
クロール範囲wp-sitemap.xml 全展開 5,586 URL + 内部リンクから発見した 475 URL=計6,061 URL
レンダリング検証Chrome headless(JS実行後DOM)で主要テンプレートを再確認
再現確認ステータス異常・一過性エラーは時間差で複数回再取得

測定できたこと・できなかったこと

できたこと: HTTPステータス、リダイレクトチェーン、canonical、meta robots、X-Robots-Tag、title、meta description、H1・見出し階層、構造化データ(JSON-LD/Microdata/RDFa)、内部リンクグラフ、クリック深度、画像属性、レスポンスヘッダ、robots.txt、サイトマップ妥当性、ページ重量、レンダーブロッキング資源、本文類似度。

当初できなかったこと → 2026-07-10 に一部を取得した: 本監査は当初、Google Search Console(GSC)にアクセスできなかった。その後 2026-07-10 にクライアント経由でGSCのエクスポートを取得し、インデックス状況・検索実績・サイトマップ処理状況を検証した(→ GSC実データ検証)。
・GSCのインデックス状況・検索実績・サイトマップ処理 → 取得・検証済み(一部はUIエクスポートの1,000行上限あり)
・検索パフォーマンス全量(1,000行超)/Core Web Vitals フィールドデータ/サーバーアクセスログ → 未取得(サービスアカウント追加で取得可能)
インデックスに関する記述の原則(更新): 当初はすべて「インデックスされうる状態にある」と控えめに記述していたが、GSCデータ取得後は、結論を出せる箇所は §13 に基づいて断定している(例: 登録済み2,918、エリアLP 4,260本の96.2%がゼロクリック、iso9001の407本はnoindexが未処理)。個別URL単位の全量照合だけは1,000行上限のため未確定で、その部分に限り推定表現を残している。
01

まず読むべき5つの要素

重大度Aの5件。評価・クロールへの直接影響がある指摘のみを抜粋する。

A-1
サイトマップの2/3が「404を返しながら中身は正常」
事象:page-2/page-3サイトマップがHTTP 404を返すが本文は正常なXML
なぜ重要か:有効な2,360URLがサイトマップ経由の発見・更新通知から丸ごと脱落
A-2
200を返す「ソフト404」が93件
事象:FAQ・スタッフ・著者等93ページが200を返しつつ中身はエラーテンプレート
なぜ重要か:全件サイトマップ収録・全件noindexなしで、価値あるコンテンツが実質失われている
A-3
noindex 458ページをサイトマップで送信し続けている
事象:noindex指定ページの全件がwp-sitemapに収録されている
なぜ重要か:「検索結果に出したい」というサイトマップの目的と矛盾するシグナルを送っている
A-4
稼働中フォームを含む5ページがHTMLとして成立していない
事象:<!DOCTYPE><html><head>を持たないHTML断片。H1が「page.php」
なぜ重要か:viewportが無くモバイル表示が崩れる。個人情報入力フォームがこの状態
A-5
エリアLP 4,260本の被内部リンク数が中央値1本
事象:被リンク中央値1本・4,093本がクリック深度3
なぜ重要か:サイトマップからも脱落(A-1)している状態でクロール到達性が二重に不足
02

指摘一覧(主要36件)

重大度ごとに区分する。A=最優先/B=インデックス品質/C=構造化データ/D=セキュリティ/E=パフォーマンス/M=監視項目(指摘リストには含めないが記録する)。

A重大度A — 評価・クロールへの直接影響(5件)
A-1

サイトマップの2/3が「HTTP 404を返しながら中身は正常」という状態にある

事象(実測)

wp-sitemap.xml は3本のページ用サイトマップを宣言している。そのうち2本がHTTP 404を返す。

サイトマップステータスContent-Type収録URL数
wp-sitemap-posts-page-1.xml200application/xml2,001
wp-sitemap-posts-page-2.xml404application/xml2,000(中身は正常なXML)
wp-sitemap-posts-page-3.xml404application/xml360(中身は正常なXML)
wp-sitemap-posts-page-4.xml 以降404text/html存在しない(正常な404)

page-2/page-3 の本文は妥当なサイトマップXMLで、収録URLは実在し200を返す(無作為10件で確認)。404は Chrome UA・Googlebot UA・bingbot UA・UAなし・HEADメソッド・時間差3回、いずれでも再現した(計6回)。CDN/WAFは介在していない(server: nginx のみ)。

Google側からも確定した(2026-07-10 GSC実データ)

GSCの表示
/wp-sitemap-posts-page-2.xml のステータス取得できませんでした
同・検出されたURL0
サイトマップインデックス全体の検出ページ合計3,223(本監査の予測 約3,226 とほぼ一致)
/wp-sitemap-posts-page-1.xml の検出URL2,001(本監査の実測と完全一致)
注意すべき表示上の罠:GSCの画面上部には緑チェックで「サイトマップ インデックスは正常に処理されました」と表示される。子サイトマップの一覧を開かない限りこの不具合には気づけない。

影響

影響は3段に分けて評価する。過大評価を避けるため確実なものから順に記載。

  1. 診断インフラの汚染(確実・最大の実害)
    page-1のサイトマップしか読まないツールは、このサイトを約3,226 URLと認識する。しかし実際は5,586 URLで、pmark-consulting/area/* の1,927本は丸ごと無視されてしまう。本監査の独立検証ツールの1つが実際にこれを踏み、「microformatsは存在しない」という誤った結論を出したため、ファクトチェックフローで確認・修正した。2026-07-02に実施した社内のページ棚卸しが認証パートナーを「3,613ページ」と数えたのも同じ原因である。これに気づかないと、サイトの4割が無視された状態で分析と意思決定が行われてしまうことになる。
  2. サイトマップ経由の発見・更新通知の喪失(確実)
    有効な2,360 URLがGoogleへのサイトマップ送信から脱落している。ただし発見経路はサイトマップだけではなく、これらのページは内部リンクからも到達可能であるため(被リンク数は中央値1本 → A-5)Googleが既に別経路で発見済みである可能性は高い。つまり、「2,360ページがインデックスされていない」ことを意味するわけではない。
  3. クロール効率への影響(限定的 — GSCデータで確定)
    本サイトの規模(5,586 URL)は、Googleがクロールバジェットの最適化対象とする基準(100万ページ超、または1万ページ超かつ日次更新)に達していない。第3の条件「Search Consoleで『検出 — インデックス未登録』に分類されるURLの割合が大きいサイト」についても、実データでは292 / 4,981 = 5.9%であり該当しない。クロールバジェットの問題としては語らない。この判定は確定した。※クロールバジェット:Googlebotが一定期間内に一括でクロールできるページの数
注意(対処の順序に関わる):脱落している2,360 URLの大半は pmark-consulting/area/* を含むエリアLPである。これはエリアLPの評価で「処遇未定」としたページ群。サイトマップを単純に復旧すると、価値判定の済んでいないページ2,360本をGoogleに再送信することになる。エリアLPの判定より先にサイトマップを"全部"復旧しない方が良さそう。復旧の対象範囲は対応計画に従うのがベター。

一般水準と出典

"If a sitemap fetch or parse fails, Google will continue trying to fetch and process the sitemap for a few days. If the attempts continue to fail, Google will stop trying to crawl that URL."
(サイトマップの取得または解析に失敗した場合、Googleは数日間は再試行する。失敗が続けば、そのURLのクロールを停止する)
"Issues affecting individual URLs within a sitemap won't prevent Google from continuing to read the sitemap, as long as the sitemap can be fetched and read in general."
(サイトマップが取得・解析できる限り、個々のURLの問題は読み取りを妨げない)

補足: サイトマップ1本あたりの上限は 50MB(非圧縮)/50,000 URL。本件はこの上限とは無関係である。

PC確認手順
  1. ブラウザで https://ninsho-partner.com/wp-sitemap.xml を開き、page-1/2/3 の3本が宣言されていることを確認
  2. Chrome DevTools(F12)→ Network タブを開いた状態で https://ninsho-partner.com/wp-sitemap-posts-page-2.xml にアクセス
  3. Network タブの Status 列が404であること、しかし Response タブには正常なサイトマップXMLが表示されることを確認
  4. Search Console → サイトマップ → wp-sitemap.xml の詳細で、Googleが検出したURL数を確認。5,586より大幅に少なければ本件が原因
  5. ターミナルで curl -I https://ninsho-partner.com/wp-sitemap-posts-page-2.xml を実行し HTTP/2 404 を確認
A-2

200を返しながら中身がエラーページになっている「ソフト404」が93件ある

事象(実測)

以下の93ページは HTTP 200 を返すが、<main> 要素の中身が丸ごとサイトのエラーテンプレート(layout__main_inner--error)で、H1が「エラー」、本文が「ページが見つかりません。URLが間違っているか、ページが削除された可能性があります。」となっている。

テンプレート件数備考
/faq/*(FAQ個別ページ)44件(全数)FAQコンテンツは一覧ページ /faq/ にのみ存在し、個別ページは全滅
/staff/*(スタッフ紹介)27件(全数)
/author/*(著者アーカイブ)9件(全数)
/glossary/letters/*(用語集の頭文字別)9件(全数)
/download/target/*(資料の目的別)4件(全数)

以下を確認した。

  • Googlebot UAでも同一(同じエラーテンプレートを返す)
  • Chrome headless のJS実行後DOMでも同一(クライアント側で復元されるわけではない)
  • 93件すべてが wp-sitemap に収録されており、93件すべてに noindex 指定が無い
  • 93件の被内部リンク数は0(サイトのナビゲーションからは既に外されている)

つまり「ナビゲーションからは消したが、サイトマップだけが送信し続けている、幽霊のようなページ」である。

影響

事業上の損失(主):FAQ 44件とスタッフ紹介27件という、指名検索や比較検討フェーズで価値を持つコンテンツが実質的に失われている。FAQの内容は一覧ページ /faq/ にのみ残り、個別ページで拾えるロングテール検索(「ISMS 契約期間 縛り」等)を取りこぼしてしまっている。

品質シグナルの汚染(副)— GSCデータにより下方修正:当初「Search Console の『ソフト404』として計上される」と判断したが、2026-07-10 のGSCエクスポートに「ソフト404」の行は存在しないサーバーエラー(5xx)robots.txt によりブロックされましたは0件の行として出力されているため、ソフト404も0件なら行が出るはずである)。

つまりGoogleは現時点で、この93件をソフト404として分類していない。おそらく「クロール済み — インデックス未登録」(1,221件)に含まれている(のちにGSCで確認)。

したがって、この指摘のSEO上の実害は当初想定より小さい。この指摘の重さは、あくまで「価値あるコンテンツが失われている」という事業上の損失にある(→ Search Console 実データによる検証結果)。

一般水準と出典

"If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error"
"For Google Search, an HTTP 2xx (success) status code doesn't guarantee indexing."
ただし対処は二択である。
  • 復元:FAQ・スタッフ紹介は事業上価値のあるコンテンツである。テンプレートの不具合であれば、まず復元を検討すべき
  • 410で明示的に削除:意図的に廃止したのであれば410(Gone)を返し、サイトマップからも除外する
どちらを選ぶかは運営側の判断であり、技術的にはどちらも正しい。現状の「200を返しながら中身が無い」だけが誤りであるため、それさえ解消できれば問題はない。なお410は再インデックスに時間がかかる操作であるため、復元の可能性が残るなら先に404で止めるのが安全。
PC確認手順
  1. Chromeで https://ninsho-partner.com/faq/faq-isms-other-01/ を開く。画面に「エラー ページが見つかりません。」と表示されることを目視確認
  2. F12 → Network タブでリロードし、当該ドキュメントの Status が200であることを確認(404ではない点が問題)
  3. Search Console → ページ(インデックス作成)→「ソフト404」の件数と対象URLを確認
  4. Search Console → サイトマップ から wp-sitemap-posts-faq-1.xml の送信URL数(44件)を確認し、上記と突合
  5. 全93件のURL一覧は本監査の付属ファイル soft404.txt を参照
A-3

noindex を指定した458ページを、サイトマップで送信し続けている

事象(実測)

meta robots に noindex を持つページが458件あり、その全件がwp-sitemapに収録されている。

内訳件数
noindex(単独)408件
noindex, nofollow50件
うち iso9001-consulting/area/*407件(同ディレクトリの全数)

X-Robots-Tag HTTPヘッダは全ページで未使用のため、noindexはmetaタグのみで指定されている。robots.txt は当該ページをブロックしていないため、noindex自体は正しくGoogleに読まれる(この点は問題ない)。

影響

サイトマップは「検索結果に表示させたいURL」を伝える手段であり、noindexページを含めることは相反するシグナルを送ることになる。たとえるならば、SNSでブロックしている相手の名前をプロフィールに書いているようなもの。

さらに以下の事実がGSCデータから判明した(→ 13-3

件数
本監査が実測した noindex ページ458
GSCが「noindex タグによって除外されました」として計上している数85
373

458件のうち408件が、404を返すサイトマップ(page-2/page-3)にのみ収録されている(うち iso9001 のエリアLP 407本すべて)。noindex はページをクロールしなければ読まれない。サイトマップから脱落し、内部リンクも中央値1本しかないページ群は十分にクロールされず、noindexの指定が Google に届いていない。

実際、全数 noindex であるはずの iso9001-consulting/area/* のうち9本が、直近16か月の検索結果に表示回数を記録している

つまり A-1(サイトマップ404)が、A-3(noindexにするという事業側の意図)の実現を阻害している。両者は独立の指摘ではなく、A-1 が A-3 の前提条件である。

本サイトの規模ではその基準に達していない(→ A-1 影響3.)ため、クロールバジェットとしては語らない。

一般水準と出典

"Include the URLs in your sitemap that you want to see in Google's search results. Google generally shows the canonical URLs in its search results, which you can influence with sitemaps."
"For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file"
PC確認手順
  1. Chromeで https://ninsho-partner.com/iso9001-consulting/area/kanto/tokyo/ を開き、右クリック→ページのソースを表示
  2. Ctrl+F(Macは Cmd+F)で「robots」を検索し、<meta name="robots" content="noindex"> があることを確認
  3. https://ninsho-partner.com/wp-sitemap-posts-page-1.xml を開き、Ctrl+F で同じURLを検索して収録されていることを確認
  4. Search Console → ページ →「noindex タグによって除外されました」の件数を確認(458に近い数字が出るはず)
A-4

稼働中の問い合わせフォームを含む5ページが、HTMLとして成立していない

事象(実測)

以下の5ページは <!DOCTYPE><html><head> も持たないHTML断片であり、H1がWordPressテンプレートのファイル名「page.php」になっている。title・meta description・canonical・meta robots・lang属性・viewport のすべてが存在しない。

URL全長内容
/lp_c05/7,186字稼働中の問い合わせフォーム(規格選択・会社名・氏名・電話番号・メールアドレス入力欄あり)
/lp_c05/lp05confirm/347字確認画面。JSで /lp_c05/ へリダイレクト
/lp_c05/lp05thanks/347字完了画面。同上
/lp_inquiry-02/lp-inquiry-02-thanks/76字完了画面
/slim_overload/slim_overload_thanks/347字完了画面。JSで /slim_overload/ へリダイレクト

5件すべてが wp-sitemap-posts-page-1.xml に収録され、200を返す。

影響

この指摘は2つの軸で重大度が異なるため、混同せずに別々で判断する。

重大度理由
SEOへの影響5ページのみ。LP系であり検索流入を狙うページではない
事業・信頼性への影響最高個人情報(会社名・氏名・電話番号・メールアドレス)を入力するフォームが、<html> も <head> も持たない状態で稼働している

<head> が無いため、viewportが無くモバイルで正しく表示されない。title が無いためSERPでのタイトルはGoogleが本文から生成する(H1が page.php であるため、これが使われる可能性がある)。

本件はSEO改善の待ち行列に入れるべきではない。テンプレートの不具合として制作側と連携する性質のものである(→ 対応計画 ゲート0)。

一般水準と出典

PC確認手順
  1. Chromeで https://ninsho-partner.com/lp_c05/ を開く
  2. 右クリック→ページのソースを表示。1行目が <h1>page.php</h1> で始まり、<!DOCTYPE html> も <head> も無いことを確認
  3. F12 → デバイスツールバー(Ctrl+Shift+M)でiPhone表示に切り替え、レイアウトが崩れることを確認
  4. ブラウザのタブに表示されるページ名がURLそのものになっている(titleが無い)ことを確認
A-5

エリアLP 4,260本の被内部リンク数が中央値1本しかない

⚠ この指摘は単独で着手してはならない。
エリアLPの処遇(統合/noindex/改善)はエリアLPの評価の節で未決定である。決定前に内部リンクを増強すると、doorway abuse に分類されるリスクのあるページ群へリンク評価を注入することになり、逆効果になりうる。判定を待つこと(→ 対応計画 ゲート2)。

事象(実測)

指標実測値
エリアLP総数4,260本(isms-consulting 1,926/pmark-consulting 1,927/iso9001-consulting 407。エリア一覧ハブ・地方・都道府県・市区町村の各階層を含む)
被内部リンク数の中央値1本
トップからのクリック深度4,093本が深度3、165本が深度2
1ページあたりの発リンク数1,870本が5本、1,870本が6本、390本が7本
サイト全体の孤立ページ(被リンク0)179件
サイト全体の準孤立ページ(被リンク1)4,557件

エリアLPが張っている内部リンクは、全4,260本が /protection_policy/、1,926本が /estimate/?from=isms-area/inquiry/?from=isms-area、といった定型のCTAのみである。

影響

被リンク1本・サイトマップからも脱落(A-1)という状態では、クロール到達性と内部リンク評価の両方が不足する。

一般水準と出典

PC確認手順
  1. Search Console → 設定 → クロールの統計情報 →「検出されたページ」でエリアLPディレクトリのクロール頻度を確認
  2. Screaming Frog(無料版500URLまで)でサイトをクロールし、Internal → Inlinks 列でエリアLPの被リンク数を確認
  3. Search Console → リンク → 内部リンク で、上位ページと下位ページのリンク数の差を確認
B重大度B — インデックス品質・重複(7件)
B-1

トラッキングパラメータ付きURLが、パラメータ込みで自己canonicalしている

事象(実測)

パラメータcanonical の指す先発生源
?a8=/column/?a8=.VwlTVDbhttps://ninsho-partner.com/column/?a8=.VwlTVDbA8.net(外部アフィリエイト)
?from_page=/download_privacy_policy/?from_page=document同URL(パラメータ込み)サイト内
?from=/inquiry/?from=isms-area同URL(パラメータ込み)サイト内。1,927ページ(エリアLP群)から内部リンク

?a8= 版と正規版の比較(実測): title 一致、meta description 一致、本文文字数 3,532字 で完全一致。つまり内容が同一のまま別URLとして自己正規化されている。Web版レポートは ?a8= ?from_page= を指摘していたが、?from= は見落としていた。これはサイト自身がエリアLPから大量に内部リンクしているもので、外部要因ではない。

影響

canonicalが正規化として機能していないため、重複URLの評価が統合されない。特に /inquiry/?from=isms-area はCVページであり、1,927ページから内部リンクされている。

一般水準と出典

"A rel="canonical" link element ... is used to indicate that another page is representative of the content on the page."
Googleは https://example.com/dresses/cocktail?gclid=ABCD のようなパラメータ付きURLではなく、正規URLを表示させることを推奨している。
"Even if you explicitly designate a canonical page, Google might choose a different canonical for various reasons"
PC確認手順
  1. Chromeで https://ninsho-partner.com/column/?a8=.VwlTVDb を開き、右クリック→ページのソースを表示
  2. Ctrl+F で「canonical」を検索。href にパラメータ ?a8=.VwlTVDb が含まれていることを確認(含まれていなければ修正済み)
  3. https://ninsho-partner.com/inquiry/?from=isms-area でも同様に確認
  4. Search Console → URL検査に https://ninsho-partner.com/inquiry/?from=isms-area を入力し、「Googleが選択した正規URL」が /inquiry/ になっているかを確認
  5. Search Console → ページ →「重複、送信されたURLが正規URLとして選択されていません」の件数を確認
B-2

canonicalがリダイレクトするURLを指している(2件)

事象(実測)

ページcanonicalの指す先指す先のステータス
/column/eruboshi//eruboshi/eruboshi/301
/column/sdgs-1-241031//sdgs/sdgs-1-241031/301

canonicalは最終的な200のURLを指すべきだが、リダイレクトするURLを指しているため矛盾したシグナルになっている。

一般水準と出典

Googleは指定されたcanonicalを常に採用するとは限らず、実装ミスがある場合は別のURLを正規URLとして選択する。

PC確認手順
  1. https://ninsho-partner.com/column/eruboshi/ のソースで canonical の値を確認
  2. その値 https://ninsho-partner.com/eruboshi/eruboshi/ をDevToolsのNetworkタブを開いた状態でアクセスし、301が返ることを確認
  3. Search Console → URL検査で「Googleが選択した正規URL」を確認
B-3

canonicalタグが存在しないページが7件

事象(実測)

/isms-consulting//iso9001-consulting//lp_c05//lp_c05/lp05confirm//lp_c05/lp05thanks//lp_inquiry-02/lp-inquiry-02-thanks//slim_overload/slim_overload_thanks/

うち5件は A-4 の「HTMLとして成立していないページ」と重複する。残る2件(/isms-consulting/ /iso9001-consulting/)はエリアLPの親ハブページであり、canonical欠落に加え /iso9001-consulting/ はH1も存在しない。

影響

canonicalが無い場合、Googleは自らシグナル(内部リンク、サイトマップ、URL構造)から正規URLを推定する。エリアLPの親ハブという重要ページでこれが起きるのは望ましくない。

一般水準と出典

"Google uses several signals to determine the canonical URL ... If you don't tell Google which URL is canonical, Google will make the choice for you."
PC確認手順
  1. Chromeで各URLを開き、右クリック→ページのソースを表示
  2. Ctrl+F で「canonical」を検索し、存在しないことを確認
  3. Search Console → URL検査に https://ninsho-partner.com/iso9001-consulting/ を入力し、「Googleが選択した正規URL」が意図した通りか確認
B-4

サイトマップに、301リダイレクトするURLが50件含まれている

事象(実測)

種別件数内容
/present/* の個別ページ36件すべて301で /present/ 1ページに集約される
/present/ 系タクソノミー5件2ホップの301(/isms/present/ → /present/present-isms-11/ → /present/)
/column/category/*7件すべて301で /column/ に集約
/others/column/others_supply_chain_strengthening/1件→ /scs/column/...
/assist/1件外部ドメイン https://3ac-assist.com/ へ301

影響

サイトマップは正規URLを伝える手段であり、301するURLを載せると Search Console のサイトマップレポートで「リダイレクトエラー」として計上される。特に /present/* の36件は、かつて個別に存在した資料ページが1ページに統合された痕跡であり、旧URLの評価が集約先で活かされているかの確認が必要。

一般水準と出典

PC確認手順
  1. Search Console → サイトマップ → wp-sitemap-posts-present-1.xml を選択し、「検出されたURL」と実際にインデックスされた数の差を確認
  2. DevTools の Network タブを開き https://ninsho-partner.com/present/9001_tanto/ にアクセス。301 → /present/ を確認
  3. curl -I https://ninsho-partner.com/assist/Location: https://3ac-assist.com/ を確認
B-5

主要な一覧ページがサイトマップに1本も収録されていない

事象(実測)

/column//faq//news//staff//voice//glossary//download//interview/ の8ページは、33本あるサイトマップのどれにも収録されていない。一方、これらは1,287〜1,291ページから内部リンクされている(サイト内で最も強く参照されているページ群)。WordPressコアの wp-sitemap.xml はカスタム投稿タイプのアーカイブページを出力しない仕様であり、これはその結果である。

影響

内部リンクが強いため発見自体はされるが、更新通知(lastmod)が送られない。一覧ページは新着記事の追加で頻繁に内容が変わるため、lastmodを伝えられないのは機会損失である。

一般水準と出典

"A sitemap is a file where you provide information about the pages, videos, and other files on your site, and the relationships between them. Search engines like Google read this file to crawl your site more efficiently."
"Google reads the <lastmod> value if it's consistently and verifiably accurate."
PC確認手順
  1. https://ninsho-partner.com/wp-sitemap.xml から各サイトマップを開き、Ctrl+F で https://ninsho-partner.com/column/ を検索。完全一致で見つからないことを確認(/column/xxx/ の個別記事は見つかる)
B-6

見出し構造の不整合

事象(実測・最終URL基準5,533ページ)

事象件数内容
H1が2個645件コラム記事の記事見出しに加え、下部の「◯◯認証取得・運用更新コンサルティングの対応エリア一覧」モジュールの見出しが <h1> になっている
H1が0個10件/interview/* 9件(h2から始まる)+ /iso9001-consulting/
H1が空文字を含む2件/assist/、/isms/column/iso27001_mark/(後者はH1が5個、うち3個が空)

影響

Googleは複数H1を許容しており、順位への直接的なペナルティはない。ただし「複数の同等の見出しがある場合」はGoogleがタイトルを書き換える条件として明示されている。

一般水準と出典

Googleがタイトルリンクを書き換える理由の一つ: "Unclear main title ... when there are multiple equally prominent headings"

注意:3ACの資料規約により既存H1文言の変更はNG(検索評価済み文言のため)。ここでの修正対象は「エリア一覧モジュールのh1をh2に降格する」ことであり、記事本体のH1文言には触れない。

PC確認手順
  1. Chromeで https://ninsho-partner.com/isms/column/27001_check-list/ を開く
  2. F12 → Console タブで document.querySelectorAll('h1').length を実行 → 2 が返る
  3. [...document.querySelectorAll('h1')].map(h=>h.textContent.trim()) を実行し、2つ目が「ISMS認証取得・運用更新コンサルティングの対応エリア一覧」であることを確認
  4. /interview/colantotte/ で同じコマンドを実行 → 0 が返る
B-7

タイトルとメタディスクリプションの品質

事象(実測・最終URL基準)

指標実測値
title 30字超5,295 / 5,533(95.7%)
title 60字超592
title 最大118字(/pmark/download/pmark_isms_businessresults/)
重複title32ページ / 14種
meta description なし5件(すべてA-4のページ)
重複description27ページ / 13種
「認証パートナー ◯◯ のご案内です。」という自動テンプレdescription345ページ
description 120字超552ページ

Web版レポートの訂正:Web版は「meta descriptionが未設定の疑い」としていたが、実際には5,533ページ中5,528に設定されている。問題は「未設定」ではなく「自動生成テンプレート文が345ページある」ことである。

一般水準と出典(重要な注記付き)

"While there's no limit on how long a <title> element can be, the title link is truncated in Google Search results as needed, typically to fit the device width."
"Write descriptive and concise text for your <title> elements."

Googleは文字数の上限を規定していない。「日本語SERPは全角約30字で見切れる」というのは実務上の経験則であり、Google公式の基準ではない。本監査では「30字超」を改善候補の抽出条件として使っているだけで、30字超が即座に問題であるとは主張しない。meta description についても同様に長さの規定はない。

PC確認手順
  1. Google検索で site:ninsho-partner.com を実行し、SERP上でタイトルがどこで切れるか目視確認
  2. Search Console → 検索パフォーマンス → ページ でCTRの低い上位表示ページを抽出
  3. Screaming Frog → Page Titles → Over X Characters で長さ超過ページを一括抽出
  4. Screaming Frog → Meta Description → Duplicate でテンプレート重複を抽出
C重大度C — 構造化データ(2件)
C-1

構造化データがコラム記事にしか存在しない

事象(実測・全5,586ページ走査、JSON-LD/Microdata/RDFaすべてを検査)

ninsho-partner.com 自身のHTMLに存在する構造化データは、以下がすべてである(リダイレクトを追跡せず、200を返す5,536ページを対象に集計)。

JSON-LD(トップレベルのエンティティ)
@type件数
BlogPosting535
VideoObject96
FAQPage4
JSON-LD(他エンティティの内部にネストされたもの)
@type件数どこに
Organization535BlogPosting の publisher および author
ImageObject535publisher の logo
WebPage535BlogPosting の mainEntityOfPage
Question / Answer各4FAQPage の内部
Microdata
itemtype件数
BreadcrumbList / ListItem1,118

RDFa:0件
JSON-LDを一切持たないページ:5,001件
パンくずマークアップを持たないページ:4,418件(79.8%)

パンくず欠落4,418ページの内訳: エリアLP 4,259 / /faq/* 44 / /staff/* 27 / /author/* 9 / /glossary/letters/* 9 / その他。エリアLPだけの問題ではない。

サイトを代表するエンティティが存在しない:単独(トップレベル)の Organization は0件。Organization は535記事の publisher としてネストされているだけで、企業そのものを表す独立したエンティティは宣言されていない。WebSite は0件(サイト内検索ボックスのリッチリザルト等の対象外)。LocalBusiness / Service / ProfessionalService — 0件。エリアLP 4,260本には構造化データが一切ない(JSON-LDもMicrodataも0。Chrome headless のJS実行後DOMでも確認済み。GTM等によるJS注入も無い)。

集計上の注記(2つの誤りを訂正済み):(1) 当初の集計ではリダイレクトを追跡していたため、/assist/(301で外部ドメイン https://3ac-assist.com/ へ転送)の構造化データを本サイトのものとして計上していた。リダイレクト非追跡で再集計し、除外した。(2) 当初はJSON-LDのトップレベル @type しか数えておらず、publisher としてネストされた Organization 535件を見落としていた。再帰的に収集して訂正した。この訂正により「Organizationはサイト全体でゼロ」から「独立したOrganizationエンティティは存在しないが、記事のpublisherとしては535件存在する」に記述が変わっている。

Web版レポートとの差:Web版は構造化データを「未測定」としていた。またパンくずは JSON-LD ではなく Microdata で実装されているため、JSON-LDだけを見ると見落とす。

一般水準と出典

PC確認手順
  1. リッチリザルトテスト https://search.google.com/test/rich-resultshttps://ninsho-partner.com/isms-consulting/area/kanto/tokyo/ を入力 →「リッチリザルトは検出されませんでした」と表示されることを確認
  2. 同じテストに https://ninsho-partner.com/isms/column/27001_check-list/ を入力 → Article と パンくずリスト が検出されることを確認
  3. Chromeで対象ページを開き F12 → Console で document.querySelectorAll('script[type="application/ld+json"]').length を実行
  4. パンくずMicrodataの確認は Console で document.querySelectorAll('[itemtype*="BreadcrumbList"]').length を実行
  5. Search Console → 拡張 → パンくずリスト/記事 のレポートで検出状況とエラーを確認
C-2

BlogPosting 535件すべてが "image": false という不正値を持つ

事象(実測)

535件すべての BlogPosting JSON-LD が以下を含む。

{ "@type": "BlogPosting", "image": false, ... }

image プロパティの型は ImageObject または URL であり、真偽値 false は型に適合しない。

一般水準と出典

"The URL to an image that is representative of the article."
型: "Repeated ImageObject or URL"

注記:image は必須プロパティではなく推奨プロパティである。したがってこれは「ガイドライン違反」ではなく「型に適合しない値が入っている実装上の不具合」として扱う。画像付きリッチリザルトの対象外になる可能性がある。

PC確認手順
  1. Chromeで https://ninsho-partner.com/isms/column/27001_check-list/ を開き、右クリック→ページのソースを表示
  2. Ctrl+F で「ld+json」を検索し、"image": false を確認
  3. リッチリザルトテストに同URLを入力し、「記事」の項目に警告が出るか確認
  4. Search Console → 拡張 → 記事 のレポートで警告件数を確認
D重大度D — HTTPS・セキュリティ・配信(6件)
D-1

www付きHTTPSが、平文HTTPを経由してからHTTPSに戻る

事象(実測)

https://www.ninsho-partner.com/
→ 301 → http://ninsho-partner.com/(平文HTTPへダウングレード)
→ 301 → https://ninsho-partner.com/(HTTPSに戻る)
→ 200

下層ページでも同様(https://www.ninsho-partner.com/column/http://ninsho-partner.com/column/https://ninsho-partner.com/column/)。https://ninsho-partner.com/index.phphttp://ninsho-partner.com/ へ301する。さらにHSTS(Strict-Transport-Security)ヘッダが apex にも www にも存在しないため、この平文ホップがブラウザ側で保護されることもない。

Web版レポートの訂正:Web版は「HTTPS強制:全http URLが301でhttpsへ転送されており、常時SSL化は機能している」を良好点として挙げていたが、これは http:// 起点のみを見た結論であり、https://www. 起点のダウングレードを見落としている。

影響

中間の平文ホップで、リクエスト内容(URL・Cookie)が傍受・改ざんされうる。リダイレクトが1ホップ余分に増える。www付きURLで到達したユーザー・クローラは常にこの経路を通る。

一般水準と出典

PC確認手順
  1. Chrome DevTools → Network タブを開き、「Preserve log」にチェックを入れる
  2. アドレスバーに https://www.ninsho-partner.com/ と入力してアクセス
  3. Network タブで最初のリクエストを選択し、Response Headers の location: が http://(sなし)で始まることを確認
  4. ターミナルで curl -sIL https://www.ninsho-partner.com/ | grep -iE "^HTTP/|^location" を実行し、チェーンを確認
  5. curl -sI https://ninsho-partner.com/ | grep -i strict-transport を実行し、何も返らない(HSTS未設定)ことを確認
  6. https://hstspreload.org/ にドメインを入力して現状を確認
D-2

セッションCookieに Secure / HttpOnly / SameSite 属性が無い

事象(実測)

トップページのレスポンスヘッダ:

set-cookie: mw-wp-form-token=...; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: PHPSESSID=...; path=/

mw-wp-form-token には3属性すべてが付いているのに対し、PHPSESSID には Secure も HttpOnly も SameSite も付いていない。

影響

SEOへの直接影響はない。セキュリティ上の指摘として記載する。Secure属性が無いCookieは、D-1の平文HTTPホップで送信されうる。

一般水準と出典

PC確認手順
  1. Chrome DevTools → Application タブ → Storage → Cookies → https://ninsho-partner.com
  2. PHPSESSID の行で Secure / HttpOnly / SameSite 列が空であることを確認
D-3

主要なセキュリティヘッダが未設定

事象(実測)

以下のヘッダがいずれも存在しない:Strict-Transport-Security / X-Content-Type-Options / X-Frame-Options / Content-Security-Policy / Referrer-Policy / Permissions-Policy

注記:これらはSEOの順位要因ではない。品質・信頼性の観点、およびISO27001/Pマークの認証コンサルティング事業者という業態を踏まえた記載である。

一般水準と出典

PC確認手順
  1. https://securityheaders.com/ にドメインを入力してスコアを確認
  2. または curl -sI https://ninsho-partner.com/ の出力を目視確認
D-4

WordPressのユーザー名が外部から列挙できる

事象(実測)

URL結果
/wp-json/wp/v2/users/200。3acadmin 等のユーザー名(slug)とGravatarハッシュをJSONで返す
/?author=1301 → /author/ad5admin/
/author/*/9件すべて200(ただし中身はsoft 404)
/wp-login.php404(ログイン画面は隠蔽されている)
/xmlrpc.php405(GETでは拒否。存在はする)
/wp-content/uploads/403(ディレクトリ一覧は無効)

ログイン画面が404である点は良好だが、ユーザー名(3acadmin, ad5admin, counter_02 等)が露出しているため、総当たり攻撃の手掛かりになる。

影響

SEOへの直接影響はない。セキュリティ指摘。

一般水準と出典

PC確認手順
  1. Chromeで https://ninsho-partner.com/wp-json/wp/v2/users/ を開き、JSONにユーザー名が表示されることを確認
  2. https://ninsho-partner.com/?author=1 にアクセスし、/author/xxx/ へリダイレクトされることを確認
E重大度E — 表示速度・レイアウト安定性(3件)
E-1

エリアLPの画像78枚すべてに width/height 属性が無く、lazy loading も指定されていない

事象(実測)

ページ<img>タグ数width/height無しlazy指定画像総容量ページ総重量
/isms-consulting/area/kanto/tokyo/7878(全数)02.79 MB約2.86〜2.90 MB
/(トップ)7660581.84 MB約2.34〜2.41 MB
/isms/column/27001_check-list/262290.79 MB約0.97 MB

エリアLPの最大画像は mv_img.png で単体972 KB。サイト全体では、width/height属性が欠落した画像を含むページが5,569 / 5,584(99.7%)

母集団の定義に関する注記:上記の分母5,584は「サイトマップ収録の全5,586URLのうち200を返したもの」である。404を返すサイトマップ page-2/page-3 に収録された2,360URLを含む(A-1参照)。page-1のみを対象にすると分母は約3,214になり、その場合の欠落率は99.8%と、比率はほぼ変わらない。所見(ほぼ全ページで欠落)は母集団の取り方に依存しない。

影響

width/height が無いと、ブラウザは画像読み込み完了までスペースを確保できず、レイアウトシフト(CLS)が発生する。lazy loading が無いと、初期表示に不要な画像まで即座に読み込まれ、LCPが遅延する。

「サイトの76%に影響」とは書かない。Core Web Vitals の実害はページ数ではなくトラフィックで加重される。エリアLPが4,260本あっても、そこに実ユーザーの流入がなければ実害はほぼゼロである。逆に、トップページとコラム記事に流入が集中しているなら、そちらの60/76枚・22/26枚の欠落のほうが実害は大きい。

判定にはフィールドデータが要る。Search Console の「ウェブに関する主な指標」にエリアLPのURLグループが一切現れない場合、それはCrUXの母数不足=流入がほぼ無いことの傍証であり、エリアLPの価値判定にも使える(→ 測定できなかった項目 U-2)。

一般水準と出典

"Always include width and height size attributes on your images and video elements. ... This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading."
"sites should strive to have a CLS of 0.1 or less for at least 75% of page visits."
Core Web Vitals の「良好」の閾値: LCP 2.5秒以内 / INP 200ms以内 / CLS 0.1以下
PC確認手順
  1. PageSpeed Insights https://pagespeed.web.dev/https://ninsho-partner.com/isms-consulting/area/kanto/tokyo/ を入力(モバイル・デスクトップ両方)
  2. 「Cumulative Layout Shift」と「Largest Contentful Paint」の値を確認
  3. 「画像要素で width と height が明示的に指定されていません」の診断項目を確認
  4. Search Console → ウェブに関する主な指標(Core Web Vitals)で、フィールドデータ(実ユーザー計測値)を確認
  5. Chrome DevTools → Lighthouse タブでモバイル計測を実行
E-2

レンダーブロッキングCSSが34本。TTFBが間欠的に1秒超へスパイクする

事象(実測)

トップページとコラム記事は <head> 内に34本の <link rel="stylesheet"> を持つ。転送量はBrotli圧縮後で84〜95 KB、非圧縮では381 KB。加えて <head> 内に同期読み込みのJSが1本ある。エリアLPはCSS 4本と軽量。

TTFB(各ページ10回計測)
ページ中央値1秒超のスパイク
/(トップ)0.21〜0.24秒発生する
/column/約0.1〜0.2秒10回中4回
/faq/約0.1〜0.2秒10回中4回
/isms-consulting/area/kanto/tokyo/約0.11秒発生する(最大11.1秒)
重要:当初「トップページのみ有意に遅い」と記述していたが、これは測定回数不足による誤りだった。独立検証(各ページ10回測定)により、1秒超のスパイクはトップ・コラム・FAQ・エリアLPを問わず全ページで間欠的に発生することが判明した。トップの温間ベースライン(約0.21秒)が深い階層(約0.11秒)よりやや重いのは事実だが、「1〜2秒」という水準ではない。

HTMLには cache-control: no-store, no-cache, must-revalidate が付いており、全リクエストで PHPSESSID が発行される。そのためHTMLは一切キャッシュされず、毎回バックエンドで生成される。スパイクの正体はトップページ固有の問題ではなく、この構成に起因するサイト全体のキャッシュミス挙動である。

注記(因果の限定):HTMLの no-store はGoogleの順位要因ではない。Googlebotはキャッシュヘッダを再クロール頻度のヒントに使う程度で、no-store が順位ペナルティになるわけではない。クロール自体は正常に行われている。これはサーバー負荷とTTFBのばらつきに影響するパフォーマンス上の論点であり、「no-store=SEOに悪影響」と短絡させてはならない。

一般水準と出典

レンダリングを妨げるリソースを削減する。
TTFB は 0.8秒以下が「良好」、1.8秒超が「不良」。
PC確認手順
  1. PageSpeed Insights に https://ninsho-partner.com/ を入力し、「レンダリングを妨げるリソースの除外」の項目を確認
  2. Chrome DevTools → Network タブ → CSS でフィルタし、リクエスト数を確認
  3. ターミナルで同じURLに対し curl -s -o /dev/null -w "%{time_starttransfer}\n" https://ninsho-partner.com/ を10回実行し、中央値とスパイクの頻度を確認(1〜2回の測定では判断しないこと)
  4. curl -sI https://ninsho-partner.com/ | grep -i cache-control でヘッダを確認
E-3

自ドメインの画像を平文HTTPで読み込むページが612件

事象(実測)

612ページが src="http://ninsho-partner.com/wp-content/uploads/..." の形で自ドメインの画像を読み込んでいる。最頻出は http://ninsho-partner.com/wp-content/uploads/2026/06/service_banner_pc.png(142ページ)。また26ページが href="http://ninsho-partner.com/..." の内部リンクを持つ(/price/ 等)。

一般水準と出典、および優先度を下げる理由

HTTPSページからHTTPでリソースを取得することは「混在コンテンツ(mixed content)」と呼ばれ、原則として避けるべきとされる。

"Mixed content refers to securely loaded web pages that use resources to be fetched via HTTP or another insecure protocol. This kind of web page is potentially unsafe."

ただし同じMDNの記述により、現代のブラウザは <img> <video> <audio> のHTTPリクエストを自動的にHTTPSへアップグレードする。

"Browsers mitigate the risks of mixed content by auto-upgrading image, video, and audio mixed content requests from HTTP to HTTPS, and block insecure requests for all other resource types."

よってユーザーが画像を見られなくなる事象は発生せず、これは衛生上の低優先項目である。ただし、将来 http→https のリダイレクトを廃止した場合に画像が表示されなくなるリスクは残る。なおGoogleはHTTPSページを検索結果で優先するが、これは混在コンテンツの有無ではなくページ自体のプロトコルを指す。

PC確認手順
  1. Chromeで対象ページを開き F12 → Console タブで Mixed Content 警告が出るか確認
  2. Console で [...document.querySelectorAll('img')].filter(i=>i.getAttribute('src')?.startsWith('http://')).length を実行
M監視項目 — 現時点では欠陥と断定しない(1件・指摘リストには含めない)
M-1

並列クロール時に誘発される一時的な5xx・接続エラー

事象(実測)

本監査のクロール(並列6・総6,061リクエスト)で3件の500を観測した。独立検証でも同じ並列度で500を5件、接続失敗を43件観測している。

URL初回観測再試行(各4〜5回+Googlebot UA)
/iso9001-consulting/area/kanto/chiba/chouseigunchounanmachi/500すべて200
/pmark-consulting/area/kinki/hyogo/amagasakishi/500すべて200
/glossary/page/2/500すべて200
重要な限定:これらはリトライで全件200に回復する。発生件数はクロールの強度とタイミングに依存し、固定値ではない。したがって以下は明確に区別する。安定して200を返さないURLは50件(すべて301)。恒久的な5xxは0件。観測された5xx・接続失敗は、並列アクセスによる負荷で誘発された可能性があり、サーバー固有の欠陥とは断定できない。

E-2で述べたとおり、HTMLに no-store が指定されており全リクエストがバックエンド生成されるため、同時接続数が増えるとバックエンドが詰まりやすい構成にはなっている。この点は監視項目として記載するが、指摘リストには含めない。

2026-07-10 のGSCデータで本項目はクローズした。インデックス作成レポートの「サーバーエラー(5xx)」は0件。Googlebotの実クロールで5xxは発生していない。本監査が観測した5xxは、並列クロールの負荷によって誘発されたものである。対応不要。

一般水準と出典

サーバーエラー(5xx)が続くとGoogleはクロール速度を落とす。
PC確認手順
  1. Search Console → 設定 → クロールの統計情報 →「レスポンス別」で 5xx の推移を確認(Googlebotの実クロールで5xxが出ているかが本質)
  2. サーバーのエラーログ(nginx / PHP-FPM)で同時刻のスタックトレースを確認

良好な点(実測で確認できたもの)

項目実測結果
HTTPS(http:// 起点)すべて301で https:// へ転送される
HTTP/2有効
圧縮Brotli(content-encoding: br)有効
robots.txtDisallow: /wp-admin/ のみ。noindexページをブロックしていないため noindex は正しく読まれる。Sitemap行あり
404の返し方存在しないURL(/404-does-not-exist-test-noa/)は正しく404を返す
末尾スラッシュ正規化/column → 301 → /column/
AIクローラGPTBot / ClaudeBot / PerplexityBot / Google-Extended / CCBot / Bytespider / Applebot-Extended すべて200(遮断していない)
ログイン画面/wp-login.php は404で隠蔽
ディレクトリ一覧/wp-content/uploads/ は403
画像altalt欠落画像を含むページは432 / 5,584(大半のページはalt付与済み)
lang属性5,528 / 5,533 で ja
ページネーション自己参照canonical(Googleの現行推奨に合致)
goo.gl/maps リンク2,317ページに存在するが、302で正常にGoogleマップへ解決する(リンク切れではない)
Web版レポートの訂正:Web版は「自動アクセス(ボット)への広範なブロック」を指摘(F16)していたが、実測ではGooglebot・bingbot・主要AIクローラすべてが200を受け取る。CDN/WAFも介在していない(server: nginx のみ)。Web版の web_fetch が拒否されたのはAnthropicのフェッチャ固有の事情であり、サイト側の遮断設定ではない。
03

追加検証で判明した指摘(計測タグ・CV導線・レンダリング後DOM)

初版の監査(curl中心)の後に実施した追加検証で判明した指摘。独立したファクトチェックで各主張を再実測し、過大主張・誤検出を除外した上で確定したものだけを載せている。特に計測タグ系(T)は、curlでは見えず、ブラウザでJSを実行した後のDOMでのみ判明する。

T-1

Meta Pixel が問い合わせフォームで二重に発火している

事象(実測・レンダリング後DOM)

/inquiry/ のレンダリング後DOMで、Meta Pixel fbq("init","796081356494853")2回実行される。ブラウザのコンソールが Duplicate Pixel ID を警告する。

ページPixel 796081356494853 の init回数
トップ /1回(正常)
/inquiry/(CVページ)2回(二重)
訂正の記録:追加検証の初報では「全ページで二重初期化」と報告されたが、独立ファクトチェックと監査者の再確認により、二重発火は /inquiry/ で発生し、トップページでは起きていないことを確定した。過大主張を訂正済み。

影響

CVページで PageView・コンバージョンが二重計上される。Meta広告のコンバージョン測定と、それに基づく自動最適化・リターゲティング母数が歪む。CVページで起きている点が特に問題で、広告のROIを実態より良く(または悪く)見せる。

一般水準と出典

同じPixel IDを複数回読み込むと重複イベントが送信される。1ページにつき1回の初期化にすべき。
PC確認手順
  1. Chromeで /inquiry/ を開き、拡張機能「Meta Pixel Helper」で PageView が2回発火していないか確認
  2. またはDevTools → Console で Duplicate Pixel ID の警告が出るか確認
  3. 対処: GTMとテーマ直書き(またはプラグイン)のどちらでPixelが二重に読み込まれているかを特定し、片方を削除
T-2

トップページだけ、別のGA4プロパティと広告アカウントが混入している

事象(実測・レンダリング後DOM)

計測IDトップ //inquiry/
G-6RX3LECR4B(GTM経由の共通GA4)ありあり
G-0TCWH74BDE(トップ限定のGA4)ありなし
AW-11352179588(トップ限定の広告)ありなし

トップページにだけ、base64のdata-URIで別のGA4プロパティと広告アカウントが直書きされている。

影響

G-0TCWH74BDE はトップのPVしか受け取らない孤立プロパティになり、計測データが分断される。どちらのGA4を正とするかが曖昧なまま2重計測されている。

PC確認手順
  1. トップと下層ページのソースで G-0TCWH74BDE を検索し、トップにのみ存在することを確認
  2. Google Tag Assistant でトップのタグ発火を確認
  3. 対処: 意図しない残置ならトップの直書きタグを削除しGTMに統一。意図的なら全ページに展開して計測を揃える
T-3

トップで広告コンバージョンタグが5種同時発火している

事象(実測)

トップのレンダリング後DOMで、Google広告のコンバージョン/リタゲIDが5種発火(10801927725 / 11352179588 / 16622016618 / 16689080952 / 17449469435)。うち3種は gtag/js ローダーも持つ。

影響

タグ肥大。使われていない旧アカウントのタグが残置していれば、計測ノイズとわずかな表示速度の負荷。過大評価はしない——5種すべてが現用なら正常な運用でもありうる。棚卸しの提案にとどめる。

PC確認手順
  1. Google広告の管理画面で現用アカウントを確認し、トップに発火する5IDと突合。不要なものを削除
T-4

キャッシュ用JSが全ページで実行時エラーを出している

事象(実測)

autoptimize_single_*.js が実ブラウザで Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') を出す(トップで再現・playwrightのコンソールで確認)。存在しない要素にイベントリスナーを登録している。

影響

何らかのUI機能が黙って動作していない可能性。curlでは検出できない。

PC確認手順
  1. DevTools → Console でエラー箇所を特定。Autoptimizeのキャッシュを再生成、またはエラーを出すスクリプトを修正
G-1

リード獲得資料へのリンクが17ページから404になっている

事象(実測)

壊れているURLステータスリンク元
/isms/download/download-isms-03/404ISMSコラム17ページから
/isms/download/download-isms-02/4041ページ
/isms/voice/isms_230713_s/4042ページ
/other/download/eruboshi_03/4041ページ(/other/ と /others/ のパス揺れ)
/news/category/seminer/4041ページ("seminar" の綴り誤り)

影響

/isms/download/download-isms-03/ はホワイトペーパー(資料ダウンロード=リード獲得)への導線で、ISMSコラム17ページから張られている。上位表示されても、資料DLというCVをこの経路で取りこぼしている。

一般水準と出典

PC確認手順
  1. /isms/column/isms_measures/ 等を開き、資料ダウンロードのリンク先が404でないか確認
  2. Search Console → リンク → 内部リンク、またはScreaming Frogで download-isms-03 へのリンク元を特定
  3. 対処: 正しい資料URLへリンク修正、資料が廃止済みなら301転送
G-2

LP用の複製ページが正規のCVページと競合している

事象(実測)

lp- / lp_ 接頭辞のページが34本存在し(thanks/confirm含む)、その本体(フォームページ)が正規のCVページと内容の重複するミラーになっている。

LP用ページ正規ページLP側の本文正規側の本文
/lp-assist_document//assist_document/505字1,297字
/lp-reserve//reserve/1,266字1,811字
/lp_inquiry-03//inquiry/577字2,666字

いずれも両方が200・自己canonical・noindex無し。LP側は本文が薄い。

影響

薄い複製が正規のCVページとタイトル重複で自己競合(カニバリ)する。※これは B-1 の固定ページcanonicalバグの影響下にあり、B-1を修正すると自己canonicalは解消される。

PC確認手順
  1. /lp-reserve//reserve/ のソースでcanonicalを比較(両方が自己参照になっているはず)
  2. 対処: LP専用ページには noindex を付ける(広告のランディング専用で自然検索に載せる必要がないため)、または正規版へcanonical
G-3

LP用フォーム /lp_c05/ にbot対策(reCAPTCHA)が無い

事象(実測)

/inquiry/ /estimate/ /document/ は reCAPTCHA を読み込むが、/lp_c05/ は外部JSがゼロでreCAPTCHA参照なし(CSRFトークンはある)。

影響

LP経由の問い合わせにスパムが混入しやすく、CVデータの品質が下がる。※このページは A-4(HTMLとして成立していない)と同じページなので、A-4の修正時に併せて対処する。

PC確認手順
  1. /lp_c05/ のソースで recaptcha を検索し、無いことを確認
G-4

メタディスクリプションに別サービスの説明が入っている(コピペ事故)

事象(実測)

/iso14001/service/iso14001-operation/ の meta description が「ISO9001「運用更新」でお困りなら…」で始まる(/iso9001/ の説明文の丸コピー)。/service/ 配下10本を精査した結果、規格名の不一致はこの1件のみ。

影響

SERPスニペットで別サービス(ISO9001)の説明が表示される。ISO14001を探しているユーザーに誤った印象を与える。

PC確認手順
  1. /iso14001/service/iso14001-operation/ のソースで <meta name="description"> を確認
G-5

主要CVページへの内部リンクが末尾スラッシュ無しで301を経由している

事象(実測)

/estimate(スラッシュ無し)が301で /estimate/ へ。スラッシュ無し版へのリンクが527ページから張られている(スラッシュ有りは3,219ページ)。

影響

CV最重要リンクに1ホップの無駄なリダイレクトが乗る。リンク評価の希釈、計測時のリファラ欠落のリスク。

PC確認手順
  1. DevTools → Network で /estimate にアクセスし301を確認。内部リンクを最終URL(スラッシュ付き)へ張り替える
G-6

CVフォームの電話番号欄がモバイル最適化されていない

事象(実測)

/inquiry/ 等のフォームで電話欄が type="text"type="tel" 未使用)、autocomplete 属性もゼロ。

影響

モバイルで数字キーパッドが出ず、自動補完も効かない。フォーム入力の摩擦がCV率に影響しうる。

一般水準と出典

PC確認手順
  1. /inquiry/ のソースで電話欄の type を確認。type="tel"autocomplete="tel" を付与
T-7

CVフォームがスクリーンリーダーで読み上げられない

事象(実測)

/inquiry/ のフォームが <dl><dt>会社名</dt><dd><input></dd> 構造で、入力欄に id が無く <label for> が0件。視覚的なラベルはあるが、プログラム的な関連付けが無い。

影響

スクリーンリーダーがフィールド名を読み上げられない(WCAG 1.3.1 / 3.3.2 / 4.1.2 に抵触)。アクセシビリティの問題であり、フォーム離脱にもつながりうる。

一般水準と出典

PC確認手順
  1. 各inputに id を付与し <label for> で関連付ける
T-6

OGP画像が「準備中」プレースホルダー、Twitter Cardメタが全ページ欠落

事象(実測)

トップ・inquiry・company の og:image が now_printing_sns.jpg(テーマ既定の「準備中」画像)。エリアLPは og:image 自体が無い。Twitter Card系メタ(twitter:card 等)が全ページ欠落。

影響

SNS・チャットでURLを共有した際に「準備中」画像が表示され、クリック率が下がる。BtoBでも商談メールやSlack共有でOGPは効く。

一般水準と出典

PC確認手順
  1. リッチリザルト系ツール、またはSNSのシェアデバッガーで表示を確認。ページ固有のOGP画像を設定

その他の低優先の指摘(一覧)

以下は実測で確認したが、影響が小さいか他の指摘に含まれるもの。

ID内容備考
G-7author アーカイブ9本が薄い重複ページ(自己canonical・noindex無し)A-3のnoindex方針に統合
G-8ページネーションに rel=prev/next が全ページ0件構造明示として付与を検討
G-9壊れたhref 2件(.com/q/...・.https:/... の記述ミス)該当2記事の本文リンクを修正
G-10/index.php が http:// へ301(プロトコル降格)D-1(www降格)と同種
G-11薄いファセットアーカイブ(glossary/letters・voice/industry・staff/role)がindexableA-3のnoindex方針に統合
T-5GTMコンテナが実行時に例外(Uncaught [object Object])GTMプレビューで該当タグを特定
T-8JSが約450KBのインラインCSSを毎ページ注入E-2のパフォーマンス群
T-9トップの画像14件にalt欠落、画像リンク19件がアクセシブルネーム無しE-1のalt欠落と関連
T-10見出し階層の飛び(company: h1→h3、top: h2→h4)B-6と関連

追加検証で「指摘しない」と判断したもの(誤報回避)

事象なぜ指摘しないか
「Meta Pixelが全ページで二重初期化」過大主張だった。独立ファクトチェックと再確認で、二重は /inquiry/ のみ・トップは単一と確定(T-1に訂正記録)
「500を返すエリアLP 2本」再測で全て200(各5回+Googlebot)。GSCの5xx 0件とも整合。M-1のクローズを維持
「?s= 検索ページにnoindex無し」シングルクオート表記で noindex, follow が正しく付与されていた(誤検出)
NAP(電話・住所)の不一致フリーダイヤル・住所は一致。画像ファイル名 IMG_0267-... を電話番号と誤認していた
hreflang 0件日本語単一言語サイトなので欠陥ではない
添付ページ・日付アーカイブの氾濫生成されていない(URL正規化は堅牢)
.git 露出無関係slugへの301で、実体は無し
04

大規模自動生成ページ(エリアLP 4,260本)の評価

この節は断定を避け、実測値と、Googleのポリシー文言と、判定に必要な追加情報を分けて記述する。

実測した類似度

各ページの <main> 内本文を抽出し、地名トークンを正規化した上で 5-gram shingle の Jaccard 類似度を算出した。「テンプレ核」=サンプルの8割以上のページに共通して出現する5-gram。つまり各ページの本文の約9割は、他の大多数のエリアLPにも出現する文字列である。

isms-consulting
91.8%
pmark-consulting
89.4%
iso9001-consulting
91.5%
上の棒=テンプレ核(8割以上のページに共通する5-gram)が本文に占める割合。
サービス全ページサンプル地名正規化後の類似度中央値類似度>0.90のペアテンプレ核が本文に占める割合
isms-consulting1,9261880.850.0%91.8%
pmark-consulting1,9271880.810.2%89.4%
iso9001-consulting407690.840.0%91.5%

「重複コンテンツ」とは断定しない

ペア類似度が0.90を超えるページはほぼ存在しない(最大0.2%)。技術的な意味での「重複コンテンツ」と断定するには不十分である。実際、各ページには地域固有の独自文が存在する。

東京都: 「丸の内・大手町のビジネス街から渋谷・六本木のスタートアップ集積地、品川・臨海部の先端技術拠点まで…」
国頭郡伊江村: 「伊江島に位置し、城山(タッチュー)とゆり祭りで知られるまちです…」

これは地名の機械的な差し替えではなく、地域ごとに書き分けられた文章である。

ただし、doorway abuse の構造要件には合致している

Googleのスパムポリシーは doorway abuse を次のように定義している。

"Doorway abuse is when sites or pages are created to rank for specific, similar search queries"
例: "Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page"
ポリシーの要件実測合致
特定の地域・都市を狙ったページを複数作成4,260本(47都道府県×市区町村)
利用者を1つのページに誘導する全4,260本が同一の2つのCTA(/estimate/?from=...、/inquiry/?from=...)へ誘導
独自の価値が無い地域固有文はある。ただし内容は観光・地理情報(城山、ゆり祭り等)でISMS/Pマークとの関連が薄い。住所・電話は東京/大阪の2拠点のみで、各地域の拠点情報は無い

△の中身を明示する

「地域ごとに書き分けられている」ことと「独自の価値がある」ことは別である。Googleの言う独自の価値とは「そのページでしか得られない、検索意図に応える価値」であり、「ISMS 取得 ◯◯市」と検索する企業担当者にとって、その市の観光名所の説明は検索意図に応えていない。文章が地域ごとに違うことは、doorway判定に対する有効な反論にはならない可能性が高い。この項目を「△」としているのは事実記述の水準であって、Googleの評価が△であることを意味しない。

断定を避けるべき境界

なぜ iso9001 だけ noindex にしたのか。その判断を isms/pmark に適用しない理由は何か。この2点は判定において、外部のポリシー解釈よりも重い材料になる。最優先でヒアリングすべきである。

判定に必要で、本監査では取得できなかった情報

  1. GSCのページインデックス登録レポート — エリアLP 4,260本の登録率と除外理由(「クロール済み―インデックス未登録」「重複、Googleにより正規URLが選択されました」の内訳)
  2. GSCの検索パフォーマンス — エリアLP群のゼロインプレッション率。90%超なら「Googleが既に価値なしと扱っている」傍証になる
  3. 事業実態のヒアリング — 各市区町村に実際のサービス提供実態・訪問体制があるか(クロールでは測れない)
この3点が揃うまで、対処方針(統合/noindex/改善)は決められない。4,260本を一括削除するような提案はしない。実績あり/なしで層別し、層ごとに三択を提示する設計が妥当である。

一般水準と出典

"Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings"
PC確認手順
  1. Search Console → ページ(インデックス作成)→ 各除外理由をクリック →「例」のURL一覧をエクスポート → area/ を含むURLの比率を算出
  2. Search Console → 検索パフォーマンス → ページ でフィルタ「URL に area を含む」を設定し、表示回数0のURL比率を確認
  3. Search Console → セキュリティと手動による対策 → 手動による対策 で「なし」であることを確認
  4. Chromeで https://ninsho-partner.com/isms-consulting/area/kyusyu/okinawa/kunigamigunieson/ を開き、地域固有の記述がサービス内容と結びついているか目視評価
05

Web版レポートとの照合(F1〜F20)

判定基準: CONFIRMED=実測で裏付け/PARTIAL=事象は正しいが記述に誤り・過不足あり/REFUTED=実測と矛盾/RESOLVED=「要確認」だった項目に実測で決着。

#Web版の主張判定実測による決着
F1?a8= パラメータで重複URLが大量生成。canonicalで統一されているか要確認RESOLVED(悪化)canonicalはパラメータ込みの自己参照(canonical="https://ninsho-partner.com/column/?a8=.VwlTVDb")。統一されていない。本文・title・descriptionは正規版と完全一致(本文長3,532字で一致)
F2?from_page= による重複URLRESOLVED(範囲拡大)同じくcanonicalがパラメータ込み自己参照。さらにWeb版が見逃した ?from= が存在し、サイト自身がエリアLP 1,926本から /inquiry/?from=isms-area 等へ内部リンクしている(外部由来でなく自作の重複URL)
F3著者アーカイブがインデックス許容。ユーザー名露出CONFIRMED(悪化)9件すべて200・noindexなし。加えて本文が丸ごとエラーテンプレート(soft 404)。/wp-json/wp/v2/users/ が200でユーザー名を列挙可能、/?author=1 → /author/ad5admin/ へリダイレクト
F4thanks/confirm ページがインデックス許容CONFIRMED/inquiry/inquiry-thanks/ 等が200・noindexなし・canonical自己参照。加えてtitle「完了画面」に対しH1「入力確認画面」の不一致
F5/feed/ が多数200。一部404で不整合CONFIRMED/column/feed/ /faq/feed/ /glossary/feed/ /author/*/feed/ 等が200。/isms/column/feed/ /eruboshi/column/feed/ は404で不整合
F6リンク資産を持つ旧URLが404CONFIRMED/%E3%81%8A%E5%95%8F%E5%90%88%E3%81%9B/(旧お問合せ)、/%E8%B3%87%E6%96%99%E8%AB%8B%E6%B1%82/(旧資料請求)、/isms/column/isms_2013/、/isms/column/isms_security_rule/ すべて404を実測
F7FAQ配下に約30件の404CONFIRMED+別問題を発見/faq/faq-isms-service-02/ 等の404を確認。さらに、サイトマップに載るFAQ 44件全てが「200を返すsoft 404」という別の問題が併存
F8末尾スラッシュ無し・旧セクションの301PARTIAL301自体は事実。ただし/feature/ のルートは301ではなく404(配下 /feature/isms/ 等は301)。また/column/eruboshi/ は301先で200だが、canonicalが301するURL /eruboshi/eruboshi/ を指すという別の欠陥がある
F9破損URL(/%20 /) /ISO /isms/colum)がインデックスに混入PARTIAL(半分は誤り)/ISO→301→/iso9001/column/iso/、/%20→301→/、/)→301→/ はいずれも正常に301処理されており破損ではない。/isms/colum /isms/colum.. は404で正常。一方Web版が見逃した実在の破損URLを発見: /iso14001/column/iso14001_emergency-test/.com/q/Q14001-2015-01.htm、/pmark/column/privacymark_website/.https:/privacymark.jp/...
F10タイトルが冗長でSERPで見切れCONFIRMED(数値化)30字超 5,295/5,533(95.7%)、60字超 592、最大118字。ただしGoogleは文字数上限を規定していない(「デバイス幅に合わせて切り詰める」とのみ)。見切れは日本語SERPの経験則として扱うべき
F11meta descriptionが未設定またはテンプレ重複の疑いPARTIAL(訂正)「未設定」は誤り。descriptionは5,533ページ中5,528に存在する。実態は「認証パートナー ◯◯ のご案内です。」という自動テンプレ文が345ページ。完全重複は最終URL基準で27ページ/13種のみ
F12#chapter-N フラグメントが別URL扱い。実害は低いCONFIRMED(Web版の判断が正しい)Googleはフラグメントを正規化する。サイトマップにも内部リンクにも実体は無く、Ahrefs集計上の見かけの問題。低優先で正しい
F13深部コンテンツへの内部リンクが弱いCONFIRMED(数値化)エリアLP 4,260本の被内部リンク数の中央値は1。被リンク0の孤立ページ179件、被リンク1の準孤立4,557件。トップからのクリック深度は4,921ページが深度3
F14サイトマップの妥当性は未確認RESOLVED(重大)wp-sitemap-posts-page-2.xml と -3.xml がHTTP 404を返しながら有効なXML本文を返す。有効な2,360URLがサイトマップ送信から脱落。加えてサイトマップ内に301が50件、noindexが458件、soft 404が93件
F15robots.txt の内容は未確認RESOLVED(問題なし)User-agent: * / Disallow: /wp-admin/ / Allow: /wp-admin/admin-ajax.php / Sitemap: のみ。noindexページをブロックしていないため、noindexは正しく読まれる。robots.txt自体に不備なし
F16自動アクセス(ボット)への広範なブロックREFUTEDGPTBot / ClaudeBot / PerplexityBot / Google-Extended / CCBot / Bytespider / Applebot-Extended すべて200。Googlebot・bingbot も200。CDN/WAFも無し(server: nginx のみ、cf-ray等なし)。Web版の web_fetch が弾かれたのはAnthropicのフェッチャ固有の事情であり、サイト側の広範なボット遮断ではない
F17Core Web Vitals 未測定PARTIAL RESOLVEDPSI匿名クォータ超過のため公式ラボ値は取得不可。代替実測: トップ総重量2.34MB/レンダーブロッキングCSS 34本。エリアLPは画像78枚すべてwidth/height無し・lazy loading 0枚・画像だけで2.79MB。フィールドデータ(実ユーザーのLCP/INP/CLS)は未取得=要GSC
F18モバイルフレンドリー未測定RESOLVED(部分的欠陥あり)5,533ページ中5,528はviewport指定あり。5ページ(LP系)はviewportもlang属性も<html>タグ自体も無い
F19構造化データ未測定RESOLVED(重大)ninsho-partner.com自身のJSON-LDトップレベルは BlogPosting 535 / VideoObject 96 / FAQPage 4 の3種のみ。5,001ページがJSON-LDを持たない。パンくずはMicrodataで1,118ページに実装、4,418ページ(79.8%)には無し。エリアLP 4,260本には構造化データが一切無い(レンダリング後DOMでも確認)。単独の Organization / WebSite / LocalBusiness / Service はゼロ(Organizationは535記事の publisher としてネストされているのみ)。BlogPosting 535件すべてが "image": false(型不一致の不正値)
F20canonical / meta robots の実装状況は未確認RESOLVEDcanonicalなし7ページ、非自己参照9ページ(サービス下層6件は親へ意図的に正規化)。X-Robots-Tagヘッダは全ページで未使用。meta robots に noindex を持つ458ページが全件サイトマップに収録されている矛盾

Web版が見つけられなかった、新規発見

#発見確度
N1サイトマップ page-2/page-3 が「404を返しながら有効なXML本文」を返し、2,360URLが送信から脱落実測・6回再現
N2200を返しながら本文が丸ごとエラーテンプレートの soft 404 が93件(FAQ全44・スタッフ全27・著者全9・用語集letters全9・download/target全4)。全件サイトマップ収録・全件noindexなし実測・Googlebot UA・レンダリング後DOMで再現
N3LP系5ページが <!DOCTYPE> <html> <head> を持たないHTML断片で、H1が page.php。うち /lp_c05/ は稼働中の問い合わせフォーム実測
N4https://www.ninsho-partner.com/ が301で平文 http:// へダウングレードしてから https に戻る。HSTS未設定実測
N5noindex 458ページ全件がサイトマップに収録(うち407はiso9001エリアLP)実測・独立検証で確認
N6同一テンプレートのエリアLPで、iso9001の407本のみ全数noindex、isms/pmarkの3,853本はインデックス許容という不統一実測・独立検証で確認
N7コラム記事645ページのH1が2個(記事見出し+「対応エリア一覧」モジュール見出し)実測
N8interview 9ページすべてにH1が存在せず、h2から始まる実測
N9サイトマップに301するURLが50件(/present/* 36件が1ページに集約、/column/category/* 7件、外部ドメイン3ac-assist.comへの301が1件)実測
N10主要一覧ページ(/column/ /faq/ /news/ /staff/ /voice/ /glossary/ /download/ /interview/)がどのサイトマップにも未収録実測
N11PHPSESSID Cookie に Secure / HttpOnly / SameSite 属性が無い実測
N12主要セキュリティヘッダ(HSTS / X-Content-Type-Options / X-Frame-Options / CSP / Referrer-Policy)が全て未設定実測
N13エリアLPの地域固有文が観光情報中心(例: 国頭郡伊江村=城山・ゆり祭り)で、認証サービスとの関連が薄い。全4,260本が同一の2つのCTAに誘導実測

実測により「指摘しない」と判断したもの(誤報回避)

事象なぜ指摘しないか
HTTP 500 が3件/iso9001-consulting/.../chouseigunchounanmachi/、/pmark-consulting/.../amagasakishi/、/glossary/page/2/ でクロール中に500を1回観測。再試行では全て200(各4〜5回+Googlebot UA)。独立検証でも同じ並列度で500×5・接続失敗×43を観測し、全てリトライで回復した。並列クロールの負荷で誘発された可能性が高く、サーバー固有の欠陥と断定できない。安定して非200なのは50件(全て301)で、恒久的な5xxは0件。監視項目に留める
goo.gl/maps リンク 2,317ページGoogleの短縮URLサービス終了の影響を疑ったが、302で正常にGoogleマップへ解決することを実測。リンク切れではない
自ドメイン画像の src="http://" 612ページ混在コンテンツだが、現代のブラウザは <img> のHTTPリクエストを自動的にHTTPSへアップグレードする(MDN)。ユーザー影響は実質なし。衛生上の低優先項目に格下げ
http://microformats.org/profile/hcard 1,927ページ<link rel="profile"> であり、混在コンテンツでも外部リンクでもない。pmark-consulting のエリアLP 1,927本にのみ存在し、他テンプレートには無い(トップ・コラム・isms系エリアLPでは0件)
/interview/page/2/ が404interview記事は9件で2ページ目が存在しない。正常動作
重複タイトル80ページ41件は301で /present/ に解決する同一ページだった。最終URL基準では32ページ/14種に訂正
「トップページのTTFBが1.2〜2.1秒で他より有意に遅い」当初のあが指摘しかけたが、独立検証で棄却された。各ページ10回測定の中央値はトップ0.21〜0.24秒、深い階層0.11秒。1秒超のスパイクは全ページで間欠的に発生しており、トップ固有の問題ではなくno-store起因のサイト全体のキャッシュミス挙動。2回程度の測定でトップだけを名指しするのは誤り
06

Search Console から取得するデータ(実施手順)

本監査の未測定項目(→ 測定できなかった項目 U-1〜U-8)と、エリアLPの判定材料(→ エリアLPの評価)を埋めるための手順。上から順に実施すれば約1時間で終わる。1〜3が最優先(エリアLPの判定に直結する)。

事前にやるべき2つ

(a) 恒久解: サービスアカウントを閲覧者に追加する
GSC → 設定 → ユーザーと権限 → ユーザーを追加 → 3ACのサービスアカウントのメールアドレスを「制限付き」で追加。これを行えば U-1〜U-6 はすべてAPI経由で自動取得できるようになり、以後この手作業は不要になる。エクスポートは応急処置である。

(b) URLプレフィックスプロパティの追加登録(任意だが強く推奨)
https://ninsho-partner.com/isms-consulting//pmark-consulting//iso9001-consulting/ の3つをURLプレフィックスプロパティとして追加登録する。検索パフォーマンスレポートの1,000行サンプル制限を、ディレクトリ単位で回避できる。
1

インデックス作成 → ページ

最優先

操作

左メニュー「ページ」→ 右上のエクスポート → Googleスプレッドシート または CSV

取れるもの

除外理由ごとの件数と、各理由のURL例(上限1,000件)

これで検証/反証される主張

見るもの監査のどの主張を検証するか
「ソフト404」の件数A-2の93件と一致するか。一致しなければ、Googleがまだ再クロールしていないか、93件以外にもソフト404がある
「noindex タグによって除外されました」の件数A-3の458件と一致するか
「クロール済み — インデックス未登録」「検出 — インデックス未登録」のURL例に占める /area/ の比率エリアLPの登録率。ここが高ければ「Googleは既に価値なしと扱っている」傍証
「重複、Googleにより正規URLが選択されました」のURL例B-1の実害の大きさ。パラメータURLが並んでいればcanonical修正の優先度が上がる
「検出 — インデックス未登録」の総URL数の比率A-1 影響3.の判定。この比率が大きければ、クロールバジェットの第3条件に該当しうる

→ U-1 が埋まる

2

インデックス作成 → サイトマップ

最優先

操作

「サイトマップ」→ wp-sitemap.xml の行をクリック → 子サイトマップ一覧を表示

取れるもの

各子サイトマップのステータスと検出URL数(エクスポートボタンは無いのでスクリーンショットで記録

これで検証/反証される主張

  • wp-sitemap-posts-page-2.xml-3.xml のステータスが「取得できませんでした」になっているか
  • wp-sitemap.xml の検出URL数が約3,226(=5,586 − 2,360)になっているか

両方が確認できれば、A-1 を「Google側から見た事実」として確定できる。現状は「監査者がcurlで観測した事実」に留まっている。

→ U-4 が埋まる

3

検索パフォーマンス → ページ

最優先・エリアLPの判定に直結
⚠ 2026-07-10 訂正:以下の計算式は誤りだった。GSCのUIエクスポートは上位1,000行で打ち切られるため成立しない。正しい手順は Search Console 実データによる検証結果(13-6) を参照。クリック数であれば確定できる。

操作

  1. 「検索パフォーマンス」→ 検索結果
  2. 期間を「過去16か月」に設定
  3. 「ページ」タブを選択
  4. 「+ 新規」→「ページ」→「次を含む」→ /area/ を入力 → 適用
  5. 右上のエクスポート

このレポートの重要な性質

表示回数が1回以上あるURLしか行として出てこない。したがって:

ゼロインプレッションのエリアLP本数 = 4,260 − エクスポートされた行数 ← 成立しない

これで検証/反証される主張

  • ゼロインプレッション率が機械的に算出できる。90%を超えるなら「Googleは既にこのページ群に価値を認めていない」という強い傍証
  • エリアLPの対処方針の層別が可能になる。表示回数・クリック数のあるエリアLPを「残す層」、ゼロインプレッションを「統合・noindexの候補層」に分けられる

→ U-6 の半分が埋まる。エリアLPの判定(ゲート2)を開ける最重要データ

4

検索パフォーマンス → クエリ×ページ(カニバリの確認)

操作

主要キーワード(「ISMS 東京」「Pマーク 取得 大阪」など10個程度)を1つずつ「クエリ」フィルタに入れ、「ページ」タブでどのURLが表示されているかを確認

見るもの

エリアLPとサービス本体ページ(/isms/ 等)のどちらが表示されているか

注意:UI上で全量を把握するのは不可能。網羅的にやるなら 設定 → 一括データエクスポート で BigQuery に日次全量を落とす。

→ U-6 の残り半分

5

エクスペリエンス → ウェブに関する主な指標

操作

「ウェブに関する主な指標」→ モバイルの「レポートを開く」→ 不良/改善が必要なURLグループをエクスポート

これで検証/反証される主張

  • エリアLPのURLグループにCLS不良が出れば、E-1の主張が実ユーザー計測で裏付けられる
  • 逆にエリアLPがこのレポートに一切現れない場合、それはCrUXの母数不足=流入がほぼゼロであることの傍証になる。この場合E-1のエリアLP分の優先度は下がり、代わりにエリアLPの価値判定の材料になる

→ U-2 が埋まる

6

設定 → クロールの統計情報

操作

「設定」→「クロールの統計情報」→「レポートを開く」(エクスポート不可。スクリーンショットで記録

見るもの

タブ何を見るか検証される主張
レスポンス別5xx の比率と推移M-1。Googlebotの実クロールで5xxが出ていなければ、M-1は完全にクローズしてよい
目的別・ファイル形式別クロール量の時系列サイトマップ破損の時期にクロール量の段差があるか。A-1の影響が発生した時期の特定
ホストのステータスrobots.txt取得・DNS・サーバー接続恒常的な問題がないか

→ U-3 が埋まる

7

セキュリティと手動による対策 → 手動による対策

操作

「問題は検出されませんでした」と表示されることを確認(スクリーンショット)

検証される主張

エリアLPの評価の前提(現時点でdoorway abuse等のペナルティを受けていない)。1分で終わる。

→ U-5 が埋まる

8

URL検査(3つのURLを個別に)

操作

上部の検索窓に以下を入力し、「Googleが選択した正規URL」を確認

入力するURL見るもの判定
https://ninsho-partner.com/inquiry/?from=isms-areaGoogleが選択した正規URLパラメータ無し版 → B-1の実害は小(Googleが自力で補正済み)/パラメータ付き → B-1の優先度を上げる
https://ninsho-partner.com/column/eruboshi/同上B-2 の実害判定
https://ninsho-partner.com/iso9001-consulting/同上B-3 の実害判定

さらに、エリアLPを1本入れて「公開URLをテスト」(ライブテスト)を実行すると、Googlebotが米国IPから見たレンダリング結果が確認できる。

→ U-8(米国IPからの見え方)が埋まる。B-1〜B-3の優先度が確定する

9

リンク → 外部リンク → 上位のリンクされているページ

操作

「リンク」→ 外部リンクの「上位のリンクされているページ」→ エクスポート

見るもの

404を返すURL(旧お問合せ /%E3%81%8A%E5%95%8F%E5%90%88%E3%81%9B/、旧資料請求 /%E8%B3%87%E6%96%99%E8%AB%8B%E6%B1%82//isms/column/isms_2013/ 等)が上位に含まれるか

含まれていれば301での転送復旧に価値がある。含まれていなければ放置してよい。

→ U-7 がAhrefsを使わずに部分的に埋まる

10

リンク → 内部リンク

操作

「リンク」→ 内部リンクの「上位のリンクされているページ」→ エクスポート

見るもの

上位1,000件にエリアLPが1本も入らないことを確認

入らなければ、A-5 の「被内部リンク数の中央値は1本」がGoogle側の集計でも裏付けられる。

取得したデータの保存先

~/ai-work/3AC/site_audit/gsc_export_20260710/ に、取得日を付けて保存する。スクリーンショットも同じ場所に。

このデータが揃った時点で、エリアLPの判定(ゲート2)に進める。
07

独立ファクトチェックの記録

本監査の全指摘は、監査者とは独立した3つの検証プロセスにより再実測・照合した。検証者には「主張を鵜呑みにせず反証を試みよ」と指示している。検証は2巡行い、2巡目でより厳密な全件再クロールを実施した。

検証結果のサマリー

検証範囲主張数CONFIRMEDPARTIALREFUTED
サイトマップ・HTTPステータス141310
soft404・インデックス制御・構造化データ201280
HTTPS・ヘッダ・robots・性能242112
合計5846102

PARTIAL の10件はいずれも「事象の指摘は正しいが件数または帰属が不正確」というものであり、指摘そのものが否定されたものは無い。REFUTED 2件のうち1件は監査者が撤回し、1件は検証者側の誤りとして退けた(後述)。

検証によって撤回・修正した主張

元の主張検証結果最終的な記述
「トップページのTTFBが1.0〜2.1秒で、他ページ(0.13〜0.25秒)より有意に遅い」REFUTED各ページ10回測定で、トップの中央値は0.21〜0.24秒。1秒超のスパイクは全ページで間欠的に発生(エリアLPで最大11.1秒)。E-2を全面改稿。「トップ固有の遅さ」ではなく「no-store起因のサイト全体のキャッシュミス挙動」と記述
「JSON-LD に Organization / WebSite / BreadcrumbList / CollectionPage が各1件」PARTIAL4件すべて /assist/ 由来で、同URLは301で外部ドメインへ転送される。クローラがリダイレクトを追跡していたことによる混入。リダイレクト非追跡で全5,586URLを再集計し、除外
「Organization はサイト全体で0件」PARTIALJSON-LDのトップレベル @type しか数えていなかった。実際は535記事の publisher として Organization がネストされている。C-1を「独立したOrganizationエンティティは存在しないが、記事のpublisherとしては535件存在する」に改稿。トップレベルとネストを分けて集計
「Microdataパンくず 1,166ページ」PARTIAL301するURL50件で転送先の内容を二重計上していた。リダイレクト非追跡で再集計し1,118ページに訂正。パンくず欠落は4,418ページ(79.8%)
「noindex 457件、iso9001エリアLP 406件」PARTIALクロール中に一過性の5xxを返したページを数え落としていた。リトライ付きで再集計し noindex 458件、iso9001エリアLP 407件(全数)に訂正
「エリアLP 4,258本」PARTIAL同上。サイトマップのURL文字列から数え直し4,260本に訂正(isms 1,926/pmark 1,927/iso9001 407)
「サイトマップ内の非200が52件(301×50+500×2)」PARTIAL安定した非200は50件(全て301)のみ。5xxは並列クロールの負荷で誘発された可能性があり、件数は測定条件に依存する。B-4・M-1を修正。リトライ付き再クロールでは5,586件が「200が5,536件・301が50件」に分かれ、恒久的な5xxは0件であることを確認
「レンダーブロッキングCSS 34本・95 KB」PARTIAL95 KBはBrotli圧縮後の転送量。非圧縮は381 KB。E-2に圧縮前後を併記
「パンくず欠落はエリアLPの問題」PARTIAL4,418ページのうち約160ページはエリアLP以外。C-1に内訳を明記

検証者の指摘を退けた主張(再々検証により監査者の記述を維持)

検証者の指摘監査者の再検証
「http://microformats.org/profile/hcard はサイト全体で0件。1,925ページという主張は虚偽」検証者のスコープ漏れ。検証者は3,214ページ(page-1サイトマップ由来)のみを巡回しており、当該記述を持つ pmark-consulting/area/* の1,927本は404を返す page-2 サイトマップにのみ収録されているため、検証者のクロール対象外だった。監査者が curl で /pmark-consulting/area/kanto/tokyo/ を直接取得し、<link rel="profile" href="http://microformats.org/profile/hcard"> の存在を再確認。件数を1,927に訂正した上で記述を維持する(なお本項目は指摘ではなく「誤検出しやすい項目」としての注記である)

この一件は、A-1(サイトマップ404)がサイト分析そのものを歪めることの実例でもある。page-1のサイトマップだけを見てクロールしたツールは、pmarkのエリアLP 1,927本の存在に気づけない。2026-07-02に実施した社内のページ棚卸しが認証パートナーを「3,613ページ」と数えていたのも、同じ原因である。

検証で再現された、指摘の核心

以下は2巡の検証を通じて一度も揺らがなかった。

母集団の定義について

本監査の「全ページ」は wp-sitemap.xml の全33本(404を返す page-2/page-3 を含む)に収録された5,586 URL + 内部リンクから発見した475 URL を指す。404サイトマップを追跡しない一般的なクロールツール(およびGoogle)が見る範囲は約3,226 URLであり、本監査の母集団はそれより2,360 URL広い。比率で示した指標(例: width/height欠落99.7%)は、どちらの母集団で計算してもほぼ変わらない。

08

Search Console 実データによる検証結果(2026-07-10 取得)

Search Console から取得するデータの手順1〜3を実施して得られたデータによる検証。監査の主張が確定したもの、撤回したもの、新たに判明した因果関係を分けて記述する。

取得条件: プロパティ https://ninsho-partner.com/ / 期間 過去16か月(2025-03-01〜2026-06-30、487日)/ 検索タイプ ウェブ

13-1. インデックス状況(既知4,981ページ)

状態ページ数比率
登録済み2,91858.6%
未登録(合計)2,06341.4%
└ クロール済み — インデックス未登録1,22124.5%
└ 検出 — インデックス未登録2925.9%
└ 見つかりませんでした(404)2464.9%
└ 代替ページ(適切なcanonicalあり)1352.7%
└ noindex タグによって除外されました851.7%
└ ページにリダイレクトがあります581.2%
└ 重複。Googleが別ページを正規ページとして選択260.5%
サーバーエラー(5xx)00.0%
└ robots.txt によりブロックされました00.0%

13-2. 監査の主張の検証結果

指摘監査の主張GSC実データ判定
A-1page-2/3が404で2,360URLが脱落page-2.xml = 取得できませんでした・検出URL 0。検出ページ合計 3,223(予測3,226)確定
A-1 影響3クロールバジェットの問題ではない「検出 — インデックス未登録」5.9%。基準に達しない確定
M-15xxは一過性で恒久欠陥ではないサーバーエラー(5xx)0件確定・クローズ
A-2「Search Consoleのソフト404として計上される」GSCに「ソフト404」の行が存在しない(0件の行は出力される形式)撤回
A-3noindex 458件をサイトマップ送信GSCの「noindexにより除外」は85件のみ。差373件意図が未実現
B-1/B-2canonicalが正規化として機能していない「重複。Googleが別ページを正規ページとして選択」26件/「代替ページ(適切なcanonicalあり)」135件実害は限定的
B-3canonical欠落7件上記に含まれる実害は限定的
F6/F7被リンクを持つ旧URLが404「見つかりませんでした(404)」246件要ドリルダウン

13-3. 新たに判明した因果関係 — A-1 が A-3 を無効化している

これは監査時点では見えていなかった。

A-1: page-2/page-3 が404
      ↓
noindex 458件のうち 408件 が page-2/3 にのみ収録されている
(iso9001-consulting/area/* の 407本すべてを含む)
      ↓
サイトマップから脱落 + 被内部リンク中央値1本 → 十分にクロールされない
      ↓
noindex はページをクロールしなければ読まれない
      ↓
GSCの「noindexにより除外」は 85件 にとどまる(458件のうち373件が未処理)
      ↓
全数noindexのはずの iso9001 エリアLP が 9本、検索結果に表示されている

結論: A-1 は A-3 の前提条件である。事業側が「iso9001のエリアLPは検索結果に出さない」と決めてnoindexを付けたにもかかわらず、サイトマップの不具合によってその意思が Google に届いていない。

これは対応計画の対応順に影響する。「エリアLPの判定が済むまでサイトマップを復旧するな」という当初の制約は、iso9001(全数noindex・407本)については逆で、復旧しないとnoindexが効かない。

13-4. エリアLP 4,260本の実績(判定材料)

重要な前提:GSCのUIエクスポートは上位1,000行で打ち切られる。したがって「ゼロインプレッション本数 = 4,260 − 行数」という当初の計算式は成立しない(→ 13-6 で訂正)。ただしクリック数は確定できる。エクスポートはクリック数の降順で、/area/ 全体の16か月クリック合計(221)と、エクスポートされた1,000行のクリック合計(221)が一致する。したがって1,000行の外にあるURLはすべてクリック0である。

エリアLPのゼロクリック率
96.2%
4,260本中4,096本が16か月でクリックゼロ
コラム記事とエリアLPの効率差
1本 ≒ 約9,459本
コラム記事1本が生む16か月クリック(491)は、エリアLP約9,459本ぶんに相当
全本数16か月クリック16か月表示回数クリック1回以上のページ数比率
isms-consulting/area/*1,92620130,0261568.1%
pmark-consulting/area/*1,9271964870.4%
iso9001-consulting/area/*(全数noindex)407114110.2%
合計4,26022134,9691643.8%

確定した事実:エリアLP 4,260本のうち、16か月でクリックを1回でも得たのは164本(3.8%)4,096本(96.2%)はクリックゼロ。/area/ 配下の16か月クリック221回は、サイト全体(352,897クリック)の0.063%。1本あたり0.052クリック/16か月(=約19本で16か月に1クリック)。

本数16か月クリック1本あたり
コラム記事(/column/ を含むURL・エクスポート内)666326,846491クリック
エリアLP4,2602210.052クリック

サイト全体のクリックの92.6%はコラム記事が生んでいる。

13-5. 判定 — 材料は揃った

必要な情報状態
GSCのページインデックス登録レポート✅ 取得済み(13-1)
エリアLP群のゼロインプレッション率⚠ 1,000行上限により算出不可。代わりにゼロクリック率 96.2% が確定
事業実態のヒアリング(各市区町村の提供体制/なぜiso9001だけnoindexにしたのか)未実施。これが最後の1ピース

実データから言えること(断定は避ける):

  1. サービス間の差が大きい。isms は1,926本で156本(8.1%)がクリックを得ているのに対し、pmark は1,927本でわずか7本(0.4%)。同一テンプレートでありながら10倍以上の開きがある。pmark のエリアLPは、isms と同じ理屈では正当化できない。
  2. iso9001 は事業側が既にnoindexにしている(407本)。その判断の理由を聞けば、pmark に同じ判断を適用すべきかが決まる。
  3. doorway abuse / scaled content abuse に該当するかは、依然としてGoogleのみが認定できる。手動による対策は現時点で受けていない。実績がゼロに近いことは「投資対効果がない」ことの証拠であって、「ポリシー違反である」ことの証拠ではない。この2つを混ぜないこと。
本数特徴選択肢
実績あり16416か月でクリック1回以上。うち156本が isms残す。地域固有情報を実サービスに結びつけて改善
実績なし・indexable約3,689クリック0。うち pmark が約1,920本noindex/統合/改善のいずれか。片道ドアなので、ヒアリング後に決定
実績なし・noindex済み407iso9001。既に事業側が価値を否認A-1を直してnoindexをGoogleに届ける(→13-3)
4,260本の一括削除はしない。

13-6. 手順の訂正

本監査が当初記載した以下の手順は誤りだった。
ゼロインプレッションのエリアLP本数 = 4,260 − エクスポートされた行数
GSCのUIエクスポートは上位1,000行で打ち切られるため、この式は成立しない。実際のエクスポートは1,000行ちょうどで、末尾行の表示回数は10だった。

正しい手順:

なお、意思決定にはゼロインプレッション率は必須ではない。クリック実績(96.2%がゼロ)と、サービス間の10倍の差の方が、判断材料として直接的である。

13-7. 対応順の更新

変更点内容
M-1 をクローズ5xx 0件。対応不要
A-2 の優先度を下げるGSCでソフト404と認識されていない。ただし「FAQ 44件とスタッフ27件が失われている」という事業上の損失は変わらない。復元か410かの判断は引き続き必要
B-1/B-2/B-3 の優先度を下げる実害26〜135件。ゲート1のチケット2は維持するが、緊急性は下がった
A-1 の位置づけを強化単独の指摘ではなく、A-3の前提条件。ゲート1で最優先
ゲート1の制約を修正「エリアLP以外に限定して復旧」→ iso9001の407本(全数noindex)はむしろ含めるべき。noindexをGoogleに届けるため。pmark 1,927本の扱いのみエリアLPの判定を待つ
判定を前倒し材料の2/3が揃った。残るは事業側へのヒアリング1点のみ。これが最後のボトルネック
09

当初測定できなかった項目 — その後の取得状況(2026-07-10 更新)

初版の監査時点でGSCにアクセスできず未測定だった8項目のうち、クライアントからGSCデータの提供を受け、5項目を取得・検証した(→ GSC実データ検証)。以下は現時点の状況である。

#項目状況結論・残作業
U-1実際のインデックス状況(登録数・除外理由)取得・結論確定登録済み2,918/未登録2,063。soft404はGoogle上「ソフト404」でなく「クロール済み-未登録」に分類、5xxは0件(→ GSC実データ検証 13-1/13-8)
U-4サイトマップに対するGoogle側の判定取得・結論確定page-2.xml「取得できませんでした」・検出URL 0、検出ページ合計3,223。A-1をGoogle側から確定(→ 13-2)
U-5手動による対策の有無未確認(1分で確定可)GSC → セキュリティと手動による対策。§6-4の前提
U-6エリアLPのクエリ実績・カニバリ一部取得クリック実績は確定(エリアLP 96.2%がゼロクリック → 13-4)。クエリ×ページのカニバリ全量はUI上限のため未確定
U-2Core Web Vitals のフィールドデータ(実ユーザーのLCP/INP/CLS)未取得GSC → ウェブに関する主な指標。E-1の優先度判定に必要
U-3Googlebot の実クロール頻度・クロール統計未取得GSC → 設定 → クロールの統計情報。M-1は5xx 0件で既にクローズ済み
U-7被リンクを持つ404URLの転送価値未取得GSCのリンクレポートまたはAhrefs。F6/G-1の301判断に必要
U-8米国IPからの見え方未取得GSC → URL検査 → ライブテスト
インデックスに関する記述の原則(更新): GSCの「登録済み/未登録」の集計とエリアLPのクリック実績は取得・確定した。したがって結論を出せる箇所は GSC実データ検証(§13)に基づいて断定している(例: 登録済み2,918、エリアLP 4,260本の96.2%がゼロクリック、iso9001の407本はnoindexが未処理)。個別URL単位のインデックス有無の全量照合だけは、UIエクスポートの1,000行上限のため未確定で、その部分に限り推定表現を残している(全量確定にはサービスアカウント追加が必要)。
10

対応計画 — 何を、いつまでに、どこで止めてよいか

2026-07-10 更新:Search Console の実データ取得により、以下が変わった(根拠は Search Console 実データによる検証結果)。
  • M-1 をクローズ(5xx 0件・対応不要)
  • A-2 / B-1 / B-2 / B-3 の優先度を引き下げ(GSC上の実害が想定より小さい)
  • A-1 を「A-3の前提条件」に格上げ。単独の指摘ではない
  • ゲート1のチケット1の制約を修正(iso9001の407本はむしろ復旧対象に含める)
  • ゲート2の入力が2/3揃った。残るは事業側へのヒアリング1点

判定に使う4つの軸

「重要度が高いからやる」という粗い分類はしない。以下の4軸で仕分ける。

問いなぜ効くか
①測定依存性それを直さないと、以後の施策の効果測定ができないかテクニカルSEOの必須群の正体は「順位を上げる施策」ではなく計測インフラの復旧である
②依存関係後続の施策の前提になっているかエリアLPの処遇の決定は、A-5・C-1のエリアLP分・E-1のテンプレ改修すべての上流。決定前に着手すると無駄打ちになる
③可逆性後から戻せるかcanonical・サイトマップ・h1降格は完全に可逆。410とnoindexの大量付与は片道ドア(再インデックスに数ヶ月)で、データが揃うまで実行しない
④実行単位改修チケットとして何件かA-1・A-3・B-4・A-2のサイトマップ除外は、指摘としては4件だが改修としては「WPサイトマップ生成の再設計」1件。指摘数ではなく改修チケット数で工数を見る

ゲート設計

ゲート0(即日〜3日)      A-4のみ。SEOと切り離す
    ↓
ゲート1(2週間以内)      ここを通過すればコンテンツ制作に移ってよい
    ↓
ゲート2(1〜2ヶ月・並走)  GSCデータ取得 → エリアLPの判定 → エリアLP系を実行 or 破棄
    ↓
常設(四半期内・並走)     セキュリティ・キャッシュ設計・description改善

ゲート0 — 即日〜3日(SEO案件として扱わない)

対象内容可逆性
A-4HTMLとして成立していない5ページ。特に稼働中の問い合わせフォーム /lp_c05/可逆

個人情報を入力するフォームが <html><head> も持たない状態で動いている。SEOの待ち行列に入れず、テンプレートの不具合として制作側へ即日一報する。

ゲート1 — 2週間以内(★コンテンツ制作の解禁条件)

この3つが揃えば、計測が信頼できる状態になる。C・D・E の完了を待つ必要はない。

#改修チケット含まれる指摘可逆性
1WPサイトマップ生成の再設計(1チケット)A-1(page-2/3の404修復)/A-3(noindex 458件の除外)/B-4(301する50件の除外)/A-2のサイトマップからの除外①測定依存可逆
2canonicalの修正B-1(パラメータ込み自己参照)/B-2(301先を指す2件)/B-3(欠落7件)①測定依存可逆
3GSCアクセス権の確保とベースライン記録Search Console から取得するデータの1〜3を実行し、現時点の数値を保存①測定依存

チケット1の制約(2026-07-10 GSCデータにより修正):当初「エリアLPの判定が済むまでエリアLP以外に限定して復旧する」としたが、実データにより一部が逆になった。

対象復旧時の扱い理由
iso9001-consulting/area/* 407本むしろ含める全数noindexだが、サイトマップ脱落によりnoindexがGoogleに届いていない(GSCの「noindex除外」は85件のみ)。復旧してクロールさせ、noindexを処理させる必要がある(→ 13-3
pmark-consulting/area/* 1,927本判定を待つindexable。16か月で7本しかクリックを得ていない(0.4%)。処遇未定のまま再送信しない
isms-consulting/area/* 1,926本判定を待つが、優先度は低い156本(8.1%)がクリックを得ており、一定の実績がある
それ以外のURL含める判定不要

page-3(360件)は全件が iso9001 のnoindexエリアLPであるため、そのまま復旧してよい。判断が要るのは page-2(pmark 1,927本を含む)である。

ゲート1を通過したと言える条件

  • wp-sitemap-posts-page-2.xml-3.xml が200を返す(またはサイトマップ構成が再設計されている)
  • ☐ サイトマップに noindex ページ・301するURL・ソフト404 が1件も含まれない
  • ?a8= ?from= ?from_page= 付きURLのcanonicalが、パラメータ無しの正規URLを指す
  • ☐ Search Console のサイトマップレポートで全サイトマップが「成功しました」になっている
  • ☐ Search Consoleから取得するデータの1〜3のエクスポートを取得し、日付を付けて保存した
→ ここまで来たら、テクニカルを離れてコンテンツ制作を開始してよい。

ゲート2 — 1〜2ヶ月(コンテンツ制作と並走。ブロックしない)

入力(2026-07-10 時点で 2/3 完了)

入力状態
GSCのインデックス状況✅ 取得済み(→ 13-1
エリアLPの検索実績✅ 取得済み(→ 13-4)。4,260本中4,096本(96.2%)がクリックゼロ
事業側へのヒアリング未実施。これが最後のボトルネック

ヒアリングで聞くべきこと(2問だけ):

  1. 各市区町村に、実際のサービス提供体制(訪問・拠点・地域限定の実績)はあるか。クロールでは測れない
  2. なぜ iso9001 のエリアLPだけを noindex にしたのか。同じ判断を pmark(1,927本・16か月で7本しかクリックなし)に適用しない理由はあるか

判定:エリアLP 4,260本を、実績あり/なしで層別し、層ごとに「統合・noindex・改善」の三択を決める。一括削除はしない。

判定が出るまで着手してはならないもの:

指摘なぜ待つか可逆性
A-5(エリアLPへの内部リンク増強)doorwayリスクのあるページ群にリンク評価を注入する恐れ可逆だが無駄打ちになる
C-1のエリアLP分(構造化データ実装)廃止するページに実装する無駄可逆だが無駄打ちになる
E-1のエリアLPテンプレ改修同上可逆だが無駄打ちになる
エリアLPの大量noindex/410片道ドア。再インデックスに数ヶ月かかる不可逆

判定後に実行するもの: A-2の最終処理(復元 or 410)、A-5、C-1のエリアLP分、E-1のテンプレ改修。

常設 — 四半期内(いつやってもよい。コンテンツ制作を止めない)

指摘内容備考
D-1wwwのHTTPSダウングレード解消+HSTS導入セキュリティ。SEO順位への影響は間接的
D-2/D-3/D-4Cookie属性・セキュリティヘッダ・ユーザー名列挙同上。ISO27001/Pマークのコンサル会社という業態を踏まえると、事業上の説得力の問題でもある
E-2HTMLキャッシュ設計の見直し(no-store 解除の可否検討)PHPSESSIDの用途特定が前提。TTFBスパイクとM-1の一過性5xxはここが根治点
C-2BlogPosting の image: false を実画像URLにテンプレート1箇所の修正で535ページに反映
B-6エリア一覧モジュールの h1 → h2 降格記事本体のH1文言は変更しない(3AC資料規約)
C-1のコラム・サービスページ分Organization / WebSite のサイト共通実装エリアLP分と切り離せばエリアLPの判定を待たずに実行できる

追加検証で判明した指摘の配置(追加検証の指摘 のG・T系)

ゲート0に追加(即日〜早め・SEOと切り離す)

指摘内容理由

ゲート1と並走(計測は事業判断の土台なので早め)

指摘内容理由
T-1Meta Pixelの二重発火解消(/inquiry/)広告のコンバージョン測定が歪んでいる。広告運用の意思決定の土台。修正は片方のPixel削除で完了
T-2トップの孤立GA4/広告アカウントの整理計測データの分断を解消
G-1リード資料リンクの404修正(17ページ)資料DL経由のCVを取りこぼしている

常設に追加(いつでも・コンテンツ制作を止めない)

指摘内容備考
G-4iso14001-operation のdescription規格名修正1ページ
G-5CVページへの内部リンクを最終URLへ張り替え527ページ分・一括置換
G-6 / T-7CVフォームの type="tel" 化とlabel関連付けフォームテンプレ1箇所
T-6OGP画像とTwitter Cardの整備SNS/チャット共有時のCTR
G-2LP複製ページにnoindex付与B-1修正で自己canonicalは解消。noindexは別途
T-3 / T-4 / T-5広告タグの棚卸し・JS実行時エラーの修正計測衛生とUI不具合

低優先(G-7〜G-11・T-8〜T-10)は他の指摘に統合されるか影響が小さく、単独の対応は不要。

明示的に「やらなくてよい」もの

これを言うのが本節の目的である。全部やる必要はない。

指摘なぜやらなくてよいか
B-5(一覧ページがサイトマップ未収録)WordPressコアの仕様。内部リンクが1,287〜1,291ページから貼られており発見に問題はない。実利が小さい
E-3(自ドメイン画像のhttp参照 612件)ブラウザが自動でHTTPSへアップグレードする(MDN)。ユーザー影響なし
M-1(一過性5xx)クローズ済み。GSCのインデックス作成レポートで「サーバーエラー(5xx)」は0件(→ 13-2)。対応不要
B-7の345ページ一括書き換えテクニカルSEOの作業ではない。コンテンツ業務に編入し、流入のある上位ページから順に対応する
A-1でエリアLP 2,360本を再送信することエリアLPの判定前に行うと、価値未判定のページをGoogleに押し込むことになる

依存関係の図

   A-4 ────────────────────────────────→ 即日(独立)

   A-1 ┐
   A-3 ├→ サイトマップ再設計 ┐
   B-4 ┘                     ├→ ゲート1 ──→ コンテンツ制作を開始してよい
   B-1 ┐                     │
   B-2 ├→ canonical修正 ─────┘
   B-3 ┘

   GSCエクスポート ──→ エリアLPの判定 ──┬→ A-5
                                          ├→ C-1(エリアLP分)
                                          ├→ E-1(エリアLPテンプレ)
                                          └→ A-2 の最終処理(復元 or 410)

   D-1〜D-4 / E-2 / C-2 / B-6 ────────────→ 常設(並走・ブロックしない)