Anchor URLs in Search Console: 9 URLs, One Real Page

When several of your URLs compete for one query, count the pages before you count the URLs. Some of those rows are anchors (/guide#setup) of one page, not separate pages. Google doesn't index them separately, so there's nothing to merge, and merging is the one move that actively breaks something.

This post gives you the check that separates a fragment split from a real conflict, the three URL shapes that inflate the count, and a case from a live account where nine competing URLs turned out to be one blog post.

TL;DR:

• Google states plainly that it "does not use fragment identifiers in indexing." /product/t-shirt#black and /product/t-shirt#white are one page to Google.
• Anchor URLs still appear in the Search Console performance report. That's display reporting, not indexing. Google's John Mueller: "They're not indexed like that... It's not a sign of a problem."
• The check is one line: strip everything after #, then count the distinct URLs left. If the answer is 1, you have a fragment split, not cannibalization. Leave ? alone: a parameter URL can be a genuinely separate page, and that one is a canonical question, not a counting artifact.
• The fix is never a redirect. There's no second page to redirect. Make the page itself the single answer to the query.

Why does one page show up as several URLs in Search Console?

Because a handful of Google's search features report on the URL a searcher actually landed on, not the canonical URL used for indexing. When Google deep-links someone into a section of your page, that deep link can surface in your performance report as its own row, sitting alongside the clean URL for the same page.

Two features do most of this. Jump links send a searcher to a named section of a page, appearing a bit like sitelinks under a result. Text fragments are the highlight-a-sentence behavior you see when you click a result and Google scrolls you to the exact sentence and highlights it, using a #:~:text= suffix on the URL.

John Mueller, Search Advocate at Google, addressed this directly when people started finding hashtag URLs in their reports:

"Most search features report on the canonical URL (the main URL used for indexing), a handful don't... Sometimes this is used to report in Search Console in your performance report. They're not indexed like that. I don't love that there's a mix of canonical & non-canonical URLs in the performance report, some savvy SEOs appreciate being able to separate them out though. It's not a sign of a problem." [3]

That last sentence is the one to hold onto. The rows aren't evidence of a problem by themselves. They become a problem only when a tool counts them and hands you an instruction based on the count.

Does Google index anchor and parameter URLs separately?

No, not anchors. Google's own documentation is unambiguous: "Google does not use fragment identifiers in indexing," with the worked example that "/product/t-shirt#black and /product/t-shirt#white are considered to be the same page by Google." [1] Elsewhere Google adds: "Don't use fragments to change the content of a page, as Google Search generally doesn't support URL fragments." [2]

Parameters are the different case, and worth keeping separate in your head. A ? URL genuinely can be a distinct URL that Google crawls, indexes, and has to pick a canonical for. Google lists "site functions: for example, the results of sorting and filtering functions" among the causes of duplicate URLs on a site. [4] So a parameter split is a real duplication question with a real answer (canonical tags, parameter handling), while a fragment split is a counting artifact with no indexing question underneath it at all.

The practical consequence: anchors can never be merged, because there is no second document. Parameters sometimes should be canonicalized. Treating them as one problem gets you the wrong fix for at least one of them.

How do you tell a fragment split from a real conflict?

Strip the fragment from every competing URL, then count what's distinct. One distinct URL means every "competing page" was the same document and the conflict is an illusion. Two or more means you have a real conflict and the three-gate test applies: both pages genuinely rank, the query has real volume, and they serve the same intent.

Worked through, on a list of nine URLs ranking for one query. Four of the rows looked like this:

• /blog/how-to-automate-app-store-screenshots-2026
• /blog/how-to-automate-app-store-screenshots-2026#fastlane
• /blog/how-to-automate-app-store-screenshots-2026#setup
• /blog/how-to-automate-app-store-screenshots-2026#:~:text=...

Cut each one at the # and all four become the same string. Do that across all nine and one document survives. The count that mattered was never nine.

This is exactly how we screen for it. The rule is one comparison: collapse the competing URLs to their documents, and if fewer than two documents survive, the flag changes from a merge instruction to a fragment instruction. Same query, same data, opposite advice, and the branch exists because pointing someone at a merge here is the single way the check can be actively wrong rather than merely noisy.

What did this look like on a real account?

Nine URLs competing for the query "fastlane mcp" across 637 impressions and zero clicks, on a live SaaS we read for 30 days. By a page-count test, that's the worst conflict on the property: nine pages, real impressions, nothing to show for it.

It was one blog post. Most of the nine were that post's own in-page section anchors, plus the clean URL. There was no second page to fold in, no redirect to write, no canonical to pick. The naive fix (merge nine pages into one) had no valid action behind it, and the real signal was different and more useful: Google was choosing between fragments of one page for this query, and landing on none of them well enough to earn a click.

Worth noting what the same account looks like once fragments are collapsed. The only other conflict it had ever flagged was its own brand name, returning the homepage, the about page, a tool page, and the blog index at position 1, with the homepage taking all 26 clicks. That's Google giving one site a block of results for its own name, which is working as intended. Between the fragment split and the brand block, the naive URL count was wrong on every conflict the property had, and its list today is empty.

What's the fix when the URLs are one page?

Make the page the single best answer to that query, and measure the clean URL. There's no merge, no redirect, no canonical decision. The work is on the page: if Google is picking between your sections, that usually means the page as a whole doesn't answer the query as directly as one of its parts does.

Three things to check on the page itself:

• Does the title and the H1 target the query? If Google is deep-linking into a subsection, the page-level signals may be pointing somewhere else. The title-writing guide covers reading the right words out of your own query data.
• Is the answer scattered? When a query's answer is spread across three sections, Google has three candidates and no obvious winner. Consolidating that answer into one clear passage near the top gives it one.
• Is the deep-linking actually fine? Sometimes it is. If the page is winning its clicks and the anchors are a deliberate deep-link surface, the honest call is to record the decision and move on rather than manufacture work.

Compare this with a genuine merge, where the mechanics matter a lot: pick the survivor, fold in the best of the others, redirect straight to the final URL rather than through a chain of hops. The decaying-page playbook covers that path. The distinction is the whole point of this post: one of these situations needs a redirect and the other cannot use one.

What can't Search Console tell you about this?

Whether the fragment rows you see are all the fragment rows there are. These are display-side reporting on features Google applies at its own discretion, so the set is neither complete nor stable, and a fragment that earned impressions last month may simply not appear this month.

Three more limits ride along:

• The join is degraded twice. Seeing this at all means joining page to query, which is the view Google drops data from for both privacy and compute reasons. Your conflict list is structurally partial before you start, as the cannibalization test covers in more detail.
• Query-level counts always under-report. Anonymized queries are omitted from the tables while still counting in your totals, so read volume at page level and treat the query view as an alignment signal.
• It can't tell you why Google chose a fragment. You see that it did. Whether that's a scattered answer, a strong section, or a SERP feature you can't influence is inference, not data.

And the limit under all of them: Search Console stops at the click. It can show you that nine rows collapsed to one page. It can't tell you what happened to the people who clicked.

Checking this without eyeballing every URL

By hand, this is a filter-and-squint job. You filter to a query, switch to the pages view, read nine URLs, mentally strip everything after the #, and realize you're looking at one post. Then you do it for the next query. It's the check that gets skipped, which is how nine URLs quietly split one query for a month.

QueryScope reads it from your editor instead. It collapses competing URLs to their documents before it counts, so a fragment split never gets reported as a nine-page conflict, and it hands over the fragment instruction rather than a merge. The same screen powers the wrong-intent checks on your own pages. For the one-line meaning of impressions or position, the Search Console glossary defines each metric with its caveat.

Sources

• Google Search Central, Ecommerce URL structure best practices ("Google does not use fragment identifiers in indexing"; "Example: /product/t-shirt#black and /product/t-shirt#white are considered to be the same page by Google").
• Google Search Central, URL structure best practices for Google Search ("Don't use fragments to change the content of a page, as Google Search generally doesn't support URL fragments").
• Search Engine Journal, Google Reassures That #Anchor URLs In GSC Are Okay (reporting John Mueller on Bluesky: "Most search features report on the canonical URL (the main URL used for indexing), a handful don't"; "They're not indexed like that... It's not a sign of a problem." Reported second-hand from a social post).
• Google Search Central, What is URL canonicalization (causes of duplicate URLs include "site functions: for example, the results of sorting and filtering functions"; a canonical preference "is a hint, not a rule").