Stop Panicking About Your CMS's Hidden URLs

2026-07-29 — stakeholder management consulting

An SEO on Reddit found URLs in their client's Squarespace site that weren't supposed to be there. They couldn't delete them. They were blocked from crawling anyway. And they were losing sleep over it.

This is the kind of thing that doesn't matter.

On Reddit, someone described the problem clearly: a link to an internal web page that was automatically created by Squarespace, a closed-source platform, was also blocked from crawling by robots.txt. The SEO had found the link buried in the raw HTML using Screaming Frog and developer tools. They couldn't edit it out. They asked Google's John Mueller directly what to do.

His answer was simple.

Google's John Mueller answered a question on Reddit about a link to an internal web page that was automatically created by Squarespace, a closed-source platform. And here's what he said: it doesn't really matter. Mueller explained that "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."

Most consultants get this wrong, including us sometimes.

We see a URL in Screaming Frog that looks wrong, and we assume it's a problem waiting to happen. We file it as a technical debt. We add it to the audit report. We recommend "fixing" it. Then the client spends three weeks trying to wrestle a hosted CMS into submission over something that has zero SEO impact.

The reason this doesn't hurt you has to do with how Google actually handles blocked URLs. Google will drop information about disallowed URLs from previous crawls, and it might index the URLs with just basic information. In addition, Google can drop those URLs from the index over time. There's no guarantee the URLs will be dropped, but that can definitely happen. More or less, Google knows the difference between a page you're actively blocking and a page you actually care about.

Squarespace's injected URLs are database identifiers masquerading as human-readable pages.

WordPress does a similar thing as well with internal identifiers. WordPress uses a term_id for categories and tags, a post_id for posts, products, pages, and attachments. Sometimes you can see those term_id and post_id in the raw HTML that WordPress generates, and just like with the Squarespace URLs, it is not anything that needs to be edited or removed for SEO purposes. It's a quirk of how these platforms work under the hood. The URLs exist in the HTML for the platform's own internal plumbing, not for human or search engine consumption.

The thing that actually matters for Google: whether a link uses proper HTML. Google can only crawl a link if it's an <a> HTML element with an href attribute. If Squarespace is injecting these as proper anchor tags, yes, Google can technically find them. But finding them and prioritizing them are different animals.

If a URL is blocked by robots.txt and serves no real purpose on your site, Google will eventually deprioritize it. Actually, that's not quite right—Google will index it with minimal information, which is the same thing from an SEO standpoint. The page won't show up in normal search results, and it won't affect your rankings.

So what should you actually care about?

Whether not-linked pages are hidden from search engines if that's what you want. Whether your internal links actually point to pages with real content. Whether your crawl budget is being wasted on pages that redirect or return 404s.

Platform-generated noise in your HTML? File it away as "platform quirk" and move on to something that actually moves the needle.