何が起きたか:CMSが自動生成したURLについてGoogleが見解
Search Engine Journalの記事(見出し:「Google On SEO Impact Of URLs Injected By CMS Platforms(CMSプラットフォームによって挿入されたURLのSEOへの影響についてのGoogleの見解)」)によると、GoogleのJohn Mueller氏が、クローズドソースのプラットフォームであるSquarespaceによって自動的に生成された内部ページへのリンクについて、Redditで寄せられた質問に回答しました。
そのページへのリンクはrobots.txt(クローラーの巡回可否を指示するファイル)によってクロールも禁止されており、記事によれば、質問者のクライアントにとっては何の役割も果たしていないように見えるものでした。質問者が困っていたのは、そのCMSが編集を許可していないためにリンクを削除できず、この意図しない内部リンク(rogue internal link)がSEO上の問題を引き起こすのではないかと懸念していた点です。
質問の詳細:robots.txtでブロック済みなのにScreaming Frogが内部リンクを検出
質問を投稿したのは、クライアントの技術的な問題を修正していたSEO担当者でした。記事によれば、その担当者は、クライアントが意図的に作成したわけではなくプラットフォームによって自動生成されたページへのリンクを削除しようとしていましたが、そのプラットフォームはリンクを削除するための編集を許可していませんでした。
そのURLはrobots.txtによってブロックされていたにもかかわらず、クロールツールのScreaming Frogは依然としてそのページを指す内部リンクを検出しており、Googleがそのページへのリンクを見つけられるのではないかという懸念につながっていました。
投稿された質問は次のとおりです。「みなさんこんにちは。クライアントの優先度の高い課題を解決していて、最後にひとつ残っています。robots.txtでブロックされている内部URLがあります。クライアントはSquarespaceを使っています。そのブロックされたページはクライアントが作成したものではなく、Squarespaceが派生的に生成したもののようで、次のような見た目をしています: https://domain/categories/=59487a4cd1758e7669102174 興味深いのは、Screaming Frogを使うとそのページへの内部リンクが見つかるのですが、それは a href の中に隠れているという点です。開発者ツール経由では見つけられたものの、Squarespaceはバックエンドへのアクセスを提供してくれないので、そのリンクをどう削除すればよいのか見当がつきません。いったい何が起きていて、どう解決すればよいのでしょうか?」
Mueller氏の回答:「検索/SEOにはまったく影響しない」
これに対してJohn Mueller氏は、そのURLと、そこを指すリンクは検索での見え方(search visibility)の問題ではないと回答し、リンクを無視することを推奨しました。
Mueller氏は次のように説明しています。「大した問題ではありません。私なら無視します。検索/SEOにはまったく影響しません。一部のプラットフォームには単にそういうリンクがあるというだけです。もしそのリンクの先にインデックスさせたいものが何も無いのであれば、あなたがすべきことは何もありません。(そして、ホスティング型のプラットフォームを使っているのであれば、そもそもできることが何も無いという可能性もあります。)」
原文では「It doesn’t really matter. I’d ignore it. It has no impact on search / SEO at all. Some platforms just have links like that, if there’s nothing behind the link that you want indexed, there’s nothing you need to do. (And possibly, there might be nothing you can do if you’re on a hosted platform.)」と述べられています。ポイントは、Mueller氏が「影響が小さい」ではなく「まったく影響しない(no impact at all)」と明言している点と、「インデックスさせたいものがリンクの先に無いのなら」という条件を付けている点です。
技術的な背景:あのランダムな文字列はCMSの内部データベースID
記事は、なぜこの種のURLが編集できないのかを技術的に整理しています。ホスティング型のCMSプラットフォームは、その土台となるテンプレート、ルーティングの仕組み、そしてJavaScriptのレンダリング処理を自らコントロールしています。だからこそ、質問者が指摘したようなSquarespace内のURLは編集できません。それらはウェブサイトの内部アーキテクチャの一部だからです。
そして記事は、あのURLがおそらくSquarespaceのデータベース内における内部URL識別子であろうと説明しています。つまり、たとえば category=shoes のような形でURLを参照する代わりに、59487a4cd1758e7669102174 のような内部データベース識別子でそれを参照している、というわけです。カテゴリ名が後から変更されても内部の参照関係が壊れないようにするための、CMSとしては真っ当な作りだといえます。
記事はあわせて、Squarespaceの開発者が使っているという確認方法も紹介しています。Squarespaceでホストされているサイトの内部データベースIDを見たい場合は、任意のURLの末尾に ?format=json-pretty を付けるだけで、Squarespaceはビジュアルなウェブページのレンダリングをやめ、そのページに対応するJSON形式のコードを出力するとしています。
WordPressも同じことをしている:term_idとpost_id
この種の内部識別子はSquarespace固有のものではありません。記事は「WordPressも内部識別子について同様のことをしているが、そちらはより目立たない形になっている。WordPressはカテゴリとタグにはterm_idを、投稿・商品・固定ページ・添付ファイルにはpost_idを使っている(WordPress does a similar thing as well with internal identifiers, only it’s more hidden away. WordPress uses a term_id for categories and tags, a post_id for posts, products, pages, and attachments.)」と説明しています。
そのうえで記事は、「Screaming Frogによるクロールを含むテクニカルSEO監査では、実は本来そこにあるべきものであるにもかかわらず、奇妙に見えるアーティファクト(artifacts)が出てくることがある(Technical SEO audits, including crawls with Screaming Frog, can turn up some weird-looking artifacts that are actually supposed to be there.)」としています。監査ツールが出した警告が、そのまま修正すべき不具合を意味するとは限らない、ということです。
記事は最後に、Squarespaceサイトをクロールする際のScreaming Frogの設定について、robots.txtに従うよう設定するか、あるいは手動で調整して特定のページをクロール対象から除外しておくと有用かもしれない、と結んでいます。
実務への影響:SEO・PPC・GEO運用のどこに効くか
今回のやり取りが実務にもたらす示唆は、クロール監査の結果を「優先度」で仕分ける判断材料が一つ増えた、という点にあります。Screaming Frogなどのクロールツールが吐き出す指摘のなかには、CMSの内部構造に由来する正常な出力が含まれます。記事が指摘するとおり、それらは本来そこにあるべきものであり、Mueller氏の回答に従えば、リンク先にインデックスさせたいコンテンツが無いかぎり検索面での対応は不要ということになります。
この切り分けができないと、修正できないものを修正しようとして時間を溶かすことになります。今回の質問者のように、クライアントのサイトで「robots.txtでブロック済みだがツールが内部リンクを検出する」という状態に直面したとき、まず確認すべきは、そのリンク先に検索結果へ出したいコンテンツが存在するかどうかです。存在しないのであれば、Mueller氏の回答どおり手を出す必要はありません。
もう一点、記事が示しているのは、監査の前段としてCMSの仕組みを理解しておくことの価値です。ホスティング型プラットフォームではテンプレートもルーティングもJavaScriptのレンダリングもプラットフォーム側が握っているため、そもそも触れない領域が存在します。触れない領域を課題リストに載せ続けても、レポートが長くなるだけで成果にはつながりません。Screaming Frog側でrobots.txtに従わせる、あるいは特定ページを除外する設定にしておく、という記事の助言は、そのノイズを最初から減らすための現実的な手当てだといえます。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。今回の話題はSquarespaceが題材ですが、日本の現場に置き換えれば、そのままWordPress・Shopify・STUDIO・ペライチといった環境の話になります。国内ではWordPressの比率が高く、テーマやプラグインが出力するアーカイブURL、添付ファイルページ、フィード、絞り込みパラメータ付きURLなど、運営者が明示的に作ったわけではないURLがHTMLに現れる場面は日常的にあります。Shopifyの商品バリアント付きURLやコレクション配下の重複経路、ノーコード系サービスが内部的に持つプレビュー用URLなども同じ系統の話です。
こうしたURLがクロールレポートに並ぶと、インハウス担当と代理店の分業体制では厄介なことが起きがちだと編集部は見ています。代理店側が機械的に「要改善」として一覧化し、インハウス側は削除方法が分からないまま宿題として抱え込む、という構図です。今回のMueller氏の回答は、その宿題の一部について「そもそも着手しなくてよい」と線を引くための、公式の根拠として使えます。監査レポートを受け取る側も出す側も、指摘を「CMS由来で対応不可・対応不要」「対応可能で効果がある」に仕分けたうえで工数を配分するのが健全でしょう。
ただし編集部としては、この回答を万能の免罪符にしないことも同じくらい重要だと考えます。Mueller氏が置いた条件は「リンクの先にインデックスさせたいものが何も無いのであれば」というものでした。裏を返せば、CMSが自動生成するURLの先に、実際には中身のあるページが大量に存在し、それらが検索結果に出てしまうケースは別問題です。自動生成されたアーカイブや絞り込み結果が薄いページとして量産されている場合には、無視ではなく設計側の手当てが必要になります。今回の件は「CMSが挿入する内部識別子のリンクそのものは無害」という話であって、「CMS由来のURLはすべて放置してよい」という話ではない、と読むのが実務的です。
まとめ
・Squarespaceが自動生成した内部URLへのリンクを削除できないという相談に対し、GoogleのJohn Mueller氏がRedditで「大した問題ではない、私なら無視する、検索/SEOにはまったく影響しない」と回答したとSearch Engine Journalが報じた
・質問者のサイトでは該当URLがrobots.txtでブロックされていたにもかかわらず、Screaming Frogがそのページへの内部リンクを検出しており、そのリンクは a href の中に隠れていた
・記事は、59487a4cd1758e7669102174 のような文字列がSquarespaceのデータベース内部のURL識別子であり、ホスティング型CMSがテンプレート・ルーティング・JavaScriptレンダリングを握っているため編集できないと説明している
・WordPressも同様に内部識別子を使っており、カテゴリとタグにはterm_id、投稿・商品・固定ページ・添付ファイルにはpost_idが割り当てられている
・テクニカルSEO監査では本来そこにあるべき奇妙な見た目のアーティファクトが検出されることがあり、記事はScreaming Frogをrobots.txtに従わせる、または特定ページを除外する設定を勧めている
よくある質問
Q1: CMSが自動で埋め込んだURLへのリンクは、削除しないとSEOで不利になりますか?
GoogleのJohn Mueller氏は、Squarespaceが自動生成した内部URLへのリンクについて「大した問題ではない、私なら無視する、検索/SEOにはまったく影響しない」と回答しています。一部のプラットフォームには単にそういうリンクがあるというだけであり、そのリンクの先にインデックスさせたいものが何も無いのであれば、すべきことは何もないとしています。またホスティング型のプラットフォームを使っている場合は、そもそもできることが何も無い可能性もあると付け加えています。
Q2: robots.txtでブロックしているのに、Screaming Frogが内部リンクを検出するのはなぜですか?
robots.txtはクローラーによる巡回を止める指示であって、HTML内のリンク記述そのものを消すものではないため、ページのソースには該当URLへのリンクが残ります。今回の質問者のケースでも、リンクは a href の中に隠れており、開発者ツールでは確認できたもののSquarespaceがバックエンドへのアクセスを提供していないため削除できませんでした。記事は、Squarespaceサイトをクロールする際はScreaming Frogをrobots.txtに従うよう設定するか、手動で特定ページをクロール対象から除外すると有用かもしれないとしています。
Q3: WordPressでも同じような内部識別子が使われているのですか?
記事によれば、WordPressも内部識別子について同様のことをしていますが、そちらはより目立たない形になっています。WordPressはカテゴリとタグにはterm_idを、投稿・商品・固定ページ・添付ファイルにはpost_idを使っているとしています。記事は、Screaming Frogによるクロールを含むテクニカルSEO監査では、本来そこにあるべきものであるにもかかわらず奇妙に見えるアーティファクトが出てくることがあると指摘しています。
出典:Google On SEO Impact Of URLs Injected By CMS Platforms(Search Engine Journal、Roger Montti氏、2026年7月29日)https://www.searchenginejournal.com/google-on-seo-impact-of-urls-injected-into-html-by-cms-platforms/584037/
