Same Homepage, Two URLs in GSC: Diagnose Position 6 vs 57

A Reddit site owner reported a striking Google Search Console split after moving from www to non-www: http://www.example.com/ averaged position 6.2 across 553 impressions, while https://example.com/ averaged 57.1 across 228 impressions. A same homepage two URLs in GSC report does not automatically prove that authority is split—but a structured audit can show whether the discrepancy is caused by reporting scope, URL variants, or an indexing problem that needs fixing.

The practical payoff is clarity before making changes. Instead of repeatedly changing canonical tags or redirects, an SEO can identify the actual ranking URL, check the Google-selected canonical, and consolidate the signals Google uses to choose one homepage version.

Start by separating the two problems

The Reddit example combines two issues that are often treated as one:

1. Multiple Search Console properties or reporting views can show different data because their URL scope differs.
2. Multiple homepage URLs appearing in Google Search can indicate that Google still sees more than one accessible or indexable version of the page.

Those are not interchangeable. Having a Domain property plus several URL-prefix properties is normal. A Domain property covers the domain without a protocol or path, while a URL-prefix property is specific to a protocol and may be specific to a path. For example, example.com, https://example.com/, and https://www.example.com/ are different property definitions even if they represent one business website.

The real concern begins when Google indexes or serves variants such as these as separate candidates:

• http://www.example.com/
• https://www.example.com/
• http://example.com/
• https://example.com/
• https://example.com/index.html
• https://example.com/?utm_source=...

A properly migrated site can still show historical URLs in reports for a period, especially after a migration. But an HTTP URL receiving hundreds of impressions after the migration deserves inspection. A redirect that works in a browser is only one signal; Google also evaluates canonical annotations, sitemap entries, internal links, HTTPS availability, and the content it can crawl.

The original Reddit post is a useful reminder that a large position gap alone is not enough evidence to diagnose diluted authority. The first task is to establish whether those rows represent two independently ranking pages or data that has been aggregated and attributed in a way that is easy to misread.

How Google Search Console calculates average position

An average position of 6.2 does not mean a homepage ranked sixth for every search. It is the average of the topmost position associated with the selected reporting scope across impressions. Search results vary by query, country, device, date, result type, and user context.

Google’s documentation makes an especially important distinction:

• In the Performance report chart, average position reflects the topmost result from the site/property.
• In a table row, such as a Page or Query row, it reflects the average position for that specific dimension.
• If more than one result from the same property appears in one result set, property-level aggregation uses the topmost site result rather than treating every visible result as an independent property impression.

That means position 6 and position 57 may reflect very different query mixes. The higher-ranking URL may appear for branded searches, local intent searches, or a small set of highly relevant queries. The lower-ranking URL may have impressions for unrelated queries, old URL references, or queries where it was only weakly eligible.

A simple worked example

Suppose https://example.com/ appears at positions 3, 8, and 160 across three impressions. Its average position is roughly 57. If http://www.example.com/ appears for two branded searches at positions 5 and 7, its average is 6.

That does not establish that one URL owns all ranking authority and the other owns none. It establishes only that their recorded impressions had very different average placements. The query-level evidence determines whether this is genuine URL competition.

This is why an SEO should avoid drawing conclusions from the Pages report alone. Position is a diagnostic clue, not a canonicalization verdict.

Use the right property: Domain property versus URL-prefix property

For most whole-site monitoring, a Domain property is the best primary view. It gathers data across protocols and subdomains under the verified domain, allowing an auditor to see whether traffic, indexing, and URLs are scattered between www, non-www, HTTP, HTTPS, and subdomains.

A URL-prefix property remains useful for controlled investigations. It is the better place to inspect one exact host and protocol, such as https://example.com/ or https://www.example.com/. Because the property is more narrowly scoped, it can make host-specific data easier to isolate.

A practical setup for a migrated website is:

Adding a property does not change rankings. Properties are reporting containers, not ranking signals. However, using only one narrow URL-prefix property can hide legacy variants that still receive impressions or remain indexed.

The key question is not, “Why are there two properties?” It is, “Which fully qualified URLs receive Search impressions, and which URL does Google currently choose as canonical?”

Find the ranking URL for the affected keywords

To learn how to see the ranking URL for keywords in GSC, use the Performance report as an evidence table rather than a summary dashboard. Set a date range that includes enough data to reduce noise—three months is often more useful than 28 days for a low-impression homepage—but compare it with the recent 28-day period when investigating a migration.

Use this sequence:

1. Open the Domain property and go to Performance > Search results.
2. Turn on Clicks, Impressions, Average CTR, and Average position.
3. Select the Pages tab and filter for the homepage variants, using an exact URL or a URL-containing filter.
4. Click one homepage URL row, then open the Queries tab.
5. Export the filtered data if the query set is large.
6. Repeat for the other homepage URL and compare the query lists, countries, devices, and dates.

This reveals whether the two URLs overlap on the same queries. If the HTTP www URL and HTTPS non-www URL both receive impressions for the same terms on the same dates, that is stronger evidence of competing variants. If each URL has a largely different query set, the gap may be explained by reporting history, canonical attribution, or different contexts in which Google tested the pages.

Watch for data attribution rules

Google generally assigns performance data to the canonical URL rather than a duplicate URL. But Google can serve a noncanonical-looking URL when it believes that version is more appropriate for a particular user or context. Therefore, a URL that appears in a report should be investigated, not dismissed solely because its redirect or canonical tag looks correct today.

For large sites, URL groups can help segment templates, directories, or URL patterns. But a group is an analytical convenience, not proof that every URL in the group has identical indexing, canonical, or Core Web Vitals behavior. A homepage investigation should start with exact URLs before expanding to groups.

Inspect every homepage variant, not just the preferred URL

The URL Inspection tool is the decisive next step. Inspect every accessible homepage variation, including the four protocol/host combinations. In Search Console, inspection requires the fully qualified URL to be within the currently selected property, so changing properties may be necessary.

For each variant, record these fields:

• URL is on Google or not indexed
• User-declared canonical
• Google-selected canonical
• Page fetch status
• Crawl allowed?
• Indexing allowed?
• Referring sitemaps
• Last crawl date

The most meaningful comparison is between the user-declared and Google-selected canonical values. A healthy post-migration pattern commonly looks like this:

If Google selects https://example.com/ as canonical for all variants, the site is likely consolidated from Google’s indexing perspective even if old URLs remain visible in some historical reporting. If Google selects a legacy URL, or the variants are all indexed separately, the audit should move to technical signal checks.

Google treats canonicalization as a selection process, not a command. A rel="canonical" is a strong preference, but Google can choose a different canonical when other signals conflict.

Verify redirects from the crawler’s point of view

A site owner may correctly report a “single 301 hop,” yet a crawler may see exceptions. Redirect testing should cover the root homepage, common homepage filenames, uppercase variants where relevant, and query parameter behavior.

At minimum, test these URLs with a crawler or HTTP header checker:

http://example.com/
http://www.example.com/
https://www.example.com/
https://example.com/
https://example.com/index.html
https://www.example.com/index.html

Each non-preferred variant should return one server-side 301 redirect directly to the canonical HTTPS non-www homepage. The preferred URL should return 200 OK. It should not redirect to a different slash, an index.html file, a locale selector, or a tracking-parameter version.

A redirect chain such as http://www → https://www → https://non-www is less efficient than a direct redirect. More importantly, inconsistent rules can create gaps: the homepage may redirect correctly while /index.html, a trailing-slash pattern, or a cached CDN host does not.

Also check whether redirect behavior changes by:

• user agent, especially Googlebot versus a standard browser;
• country or CDN edge location;
• HTTP method, where relevant;
• cookies, language redirects, or consent tooling;
• IPv4 versus IPv6 infrastructure.

Server-side redirects are the clearest migration signal. Meta refreshes and JavaScript redirects are weaker and can complicate crawling. A page that returns 200 OK with a canonical tag is not functionally equivalent to a URL that permanently redirects away; both may be useful signals, but they solve different parts of consolidation.

Align canonical tags, internal links, and sitemap URLs

Canonical consistency is an ecosystem, not a single tag. If the preferred homepage is https://example.com/, every controllable signal should reinforce that precise URL.

The consolidation checklist

• The preferred homepage returns 200 OK and includes a self-referencing canonical: https://example.com/.
• HTTP and www equivalents issue direct 301 redirects to that preferred URL.
• Internal navigation, logos, footer links, breadcrumbs, hreflang annotations, and structured-data URLs use the preferred host and protocol.
• XML sitemaps include only canonical, indexable HTTPS non-www URLs.
• Canonical tags do not point to redirects, blocked URLs, noindexed pages, or URLs with tracking parameters.
• The robots.txt file does not block the preferred homepage or its key assets.
• External platforms under the site’s control—Google Business Profile, social profiles, advertising landing pages, email templates, and major partner listings—are updated where feasible.

Internal links matter because Google uses links to discover pages and understand relevance. A navigation template that still points to https://www.example.com/ sends a repeated contradictory signal sitewide, even if that URL redirects. Likewise, an XML sitemap is a canonicalization hint; it should not list retired variants.

This wider check is particularly important after a migration. Google’s site-move guidance recommends updating a site’s own links and submitting the new sitemap rather than relying on redirects indefinitely. For a broader prioritization framework, see an audit plan that prioritizes fixes.

Do not confuse indexing symptoms with a homepage canonical issue

A homepage canonical problem can coexist with broader indexing issues, but the fix is not always the same. For example, an Indexing report showing one indexed URL for a large site is usually a coverage, discovery, quality, robots, or canonical problem across many pages—not just a www/non-www problem.

When numerous sub-pages are missing, the audit should examine each Page indexing reason separately. A URL marked “Discovered – currently not indexed” needs a different diagnostic path from a duplicate homepage that redirects. The guide to Discovered – currently not indexed diagnostics explains why submitting the same URL again is rarely the full answer.

Similarly, a site where Search Console appears to index one page out of 180 needs inventory-level checking: crawlability, canonical targets, sitemaps, internal links, content duplication, and server responses. The pattern is covered in Google Search Console only one page indexed.

Keep Core Web Vitals in the right place

Core Web Vitals can affect user experience and are worth auditing, but they do not replace canonical diagnostics. A poor LCP, INP, or CLS result does not explain why http://www is indexed instead of https://non-www.

It can still be useful to review performance by URL pattern after canonical consolidation. Search Console and third-party tools may report Core Web Vitals differently because their data sources, URL grouping, and field-versus-lab methodology differ; this comparison of GSC and Semrush Core Web Vitals explains the practical differences.

A compact decision tree for position 6 versus 57

Use this decision tree before altering site-wide rules:

1. Are the URLs in different Search Console properties only?

If yes, compare them inside the Domain property. Different properties alone do not indicate a ranking problem.

1. Do both exact URLs appear in the Pages dimension of the Domain property?

If no, the perceived split may be property scoping or historical reporting.

1. Do both URLs receive impressions for the same queries and dates?

If no, compare query intent before assuming competition.

1. Does URL Inspection show one Google-selected canonical?

If yes, Google has likely clustered the variants; continue monitoring rather than making repeated changes.

1. Does a legacy variant return 200 OK or have a Google-selected canonical pointing to itself?

If yes, fix the redirect/canonical conflict and check all related variants.

1. Do internal links or sitemaps still promote the legacy URL?

If yes, update those sources and resubmit the canonical sitemap.

1. Is the issue limited to a few URLs after the technical fixes are live?

Request indexing for a small number of important URLs using URL Inspection. For many changed URLs, submit an updated sitemap rather than requesting individual recrawls.

This sequence prevents a common waste of effort: changing a canonical tag that is already correct when the actual issue is an edge-case redirect, a legacy sitemap URL, or a misunderstanding of average position.

A practical audit workflow for agencies and site owners

An agency audit should preserve evidence before changing anything. Export the Performance report for both homepage variants, capture URL Inspection results, and crawl the URL set with redirects enabled. That baseline is useful for explaining the issue to a client and for checking whether Google’s canonical selection changes after remediation.

A local audit tool can speed up the repeatable parts: crawl the site for internal-link host inconsistencies, detect status-code and canonical conflicts, identify sitemap URLs that redirect, and flag homepage variants that still return 200. Audra is designed for this kind of local-first review alongside technical SEO, performance, accessibility, best-practice, link, and AI visibility checks—without requiring a recurring cloud subscription.

After fixes are deployed, use this verification checklist:

1. Re-crawl the four main protocol/host homepage variants.
2. Confirm exactly one version returns 200 OK.
3. Confirm all noncanonical variants make one direct 301 hop.
4. Confirm the preferred page has a self-referencing canonical.
5. Confirm navigation and sitemap files use only the preferred URL.
6. Inspect the preferred URL and at least one legacy variant in Search Console.
7. Monitor the Domain property over the next several weeks, comparing query-level and page-level data rather than relying on a single daily position value.

Request validation only when Search Console identifies a fixable grouped indexing issue that supports validation. For ordinary canonical adjustments, validation is less useful than confirming the live technical state, submitting the updated sitemap, and allowing Google to recrawl. A manual request can be appropriate for a small number of business-critical URLs, but it cannot force Google to choose a particular canonical.

FAQ

Why does Google Search Console show two URLs for the same homepage?

Google Search Console can show two homepage URLs because the property includes multiple protocols or hosts, because historical variants still have data, or because Google has not fully consolidated duplicate URLs. Check the Domain property first, then inspect both exact URLs. The key evidence is the Google-selected canonical and whether the legacy URL returns a direct 301 redirect.

Does having www and non-www versions split authority or rankings?

Merely having both www and non-www properties in Search Console does not split authority or rankings; properties are reporting views. Problems arise when both URL versions remain accessible, indexable, internally linked, or inconsistently canonicalized. A consistent 301 redirect, canonical URL, internal-link pattern, and sitemap help Google consolidate duplicate signals into the preferred version.

Why can the same homepage appear at position 6 and position 57 in GSC?

Average position is calculated across impressions, not from one fixed ranking. One URL may receive branded-query impressions near position 6, while another receives a different mix of impressions averaging near 57. Compare the Queries tab after filtering each exact page URL. The position difference alone does not prove that Google has split ranking signals.

How can an SEO identify which URL is actually ranking for a query?

In the Performance report, filter to the query, then open the Pages tab to see the URLs associated with that query. Repeat the check for the affected date range, country, and device where possible. Then use URL Inspection to see the Google-selected canonical. This combines observed performance data with Google’s indexing decision.

Should a website use a Domain property or a URL-prefix property in Search Console?

A Domain property is generally best for whole-site monitoring because it covers protocol and subdomain variants. URL-prefix properties are useful for diagnosing one precise host, protocol, or path, such as https://example.com/. Many SEO teams keep both: the Domain property for reporting and URL-prefix properties for focused inspection and troubleshooting.