Should you really create a new Search Console property when migrating to HTTPS?

Why does Google recommend a separate Search Console property for HTTPS?

This recommendation is based on a fundamental technical principle: HTTP and HTTPS are considered two distinct protocols by search engines. During a migration, you are technically switching from one site to another, even if the domain remains the same.

Google treats this transition like a classic migration. The engine must reindex all of your URLs under their new secure form, redistribute ranking signals, and gradually transfer the accumulated authority from the old HTTP URLs.

What is the tangible benefit of having two separate properties?

The main benefit lies in the granular tracking of the migration. With two distinct properties, you can precisely monitor the downward trend of HTTP traffic and the gradual increase of HTTPS traffic. This visibility helps to quickly identify issues: missing redirects, orphaned pages, abnormal drops in rankings.

You can also compare performance before/after over an identical period. Click, impression, and position data remain compartmentalized by protocol, making it easier to diagnose if the migration negatively impacts certain queries.

Does this approach remain relevant with the evolution of Search Console?

Mueller's recommendation dates back to a time when URL prefix properties were the norm. Since the introduction of domain properties, Google allows grouping all variants (HTTP, HTTPS, www, non-www, subdomains) under a single unified view.

This development raises a question: should separate properties still be created or is a domain property sufficient? Mueller's statement remains technically correct, but the optimal approach depends on your reporting needs. A domain property simplifies long-term management, while separate properties provide valuable granularity during the transition.

• HTTP and HTTPS are treated as two distinct sites by Google during indexing
• Creating an HTTPS property allows for detailed tracking of the migration and facilitates diagnosis
• Domain properties offer an alternative that unifies all URL variants under a single interface
• The temporary granularity of separate properties remains useful for complex or high-traffic sites
• No technical obligation: you can choose the approach that fits your reporting constraints

Is this statement consistent with observed practices?

Mueller's recommendation indeed reflects what happens behind the scenes: Google treats HTTP and HTTPS as two distinct entities during the migration phase. Server logs clearly show that Googlebot explores both versions simultaneously for several weeks, even with 301 redirects in place.

Let’s be honest: this approach has long been the only solution for properly tracking an HTTPS migration. However, it has a major drawback — it complicates post-migration management. You're left with historical HTTP properties that need to be maintained for retrospective analysis, while juggling HTTPS data for daily operations.

What nuances should be added to this recommendation?

Mueller does not mention a critical point: creating a new property is not mandatory if you use a domain property. This option existed when he made his statement, but it hadn't been widely adopted yet. [To be verified]: Google has never officially confirmed whether a domain property captures migration data with the same granularity as two separate properties.

Another nuance: for small sites (fewer than 1000 pages), creating a distinct property may be over-engineering. If your redirects are correctly configured and you don’t need in-depth comparative analyses, a single property is more than sufficient.

In what cases does this approach become counterproductive?

Agencies managing dozens of client sites face a property inflation that is hard to maintain. Each HTTPS migration doubles the number of entries in Search Console, complicating consolidated reporting and increasing the risk of human error (wrong property selected, analysis based on outdated data).

More problematic: if you are migrating a site that already has multiple subdomains or variants (mobile/desktop, multiple languages), you can quickly end up with more than 10 active properties. At this point, management becomes chaotic, and the domain property approach becomes necessary.

What should you do before migrating to HTTPS?

Start by creating your new HTTPS property in Search Console before technically switching. Add it with the correct prefix (https://example.com or https://www.example.com based on your final setup). This forethought ensures that you have the necessary access and that the property is properly linked to your Analytics account if you are using integrated tracking.

Next, submit an HTTPS sitemap in this new property as soon as your 301 redirects are in place. Googlebot will discover the new URLs through these redirects, but a sitemap significantly speeds up the reindexing process. You easily gain a few days on the overall migration duration.

How can you effectively monitor the transition between the two properties?

Set up a dashboard with key metrics from both properties side by side: total clicks, average impressions, average position, crawl errors. The goal is to detect when HTTPS traffic exceeds HTTP traffic — that’s your indicator that the migration is progressing normally.

Be particularly attentive to coverage errors in the HTTPS property. If you see pages flagged as “Detected but not indexed” or “Crawled but not indexed” when they were indexed in HTTP, that’s a warning sign. Check your redirects, your HTTPS robots.txt, and ensure your canonicals point to the HTTPS versions.

When can you abandon the old HTTP property?

Never completely delete an HTTP property after migration. Keep it as read-only for historical purposes. You will need this data for comparative analyses, client audits, or to demonstrate the positive (or negative) impact of the migration in the long term.

Specifically, wait at least 6 months after migration before stopping active monitoring of the HTTP property. At this point, HTTP traffic should be negligible (less than 5% of the total). If this is not the case, it means that some redirects may be missing or that third-party sites continue to link to your old URLs.

• Create the HTTPS property in Search Console before the technical switch
• Verify that both properties are linked to the same Google Analytics account
• Submit a complete HTTPS sitemap once the 301 redirects are active
• Monitor coverage errors on the HTTPS property daily for 3 weeks
• Compare the traffic curves of HTTP vs. HTTPS to validate the progress of the migration
• Keep the HTTP property read-only for at least 12 months for retrospective analyses