Choose the preferred public host first
Write the complete preferred service URL, including HTTPS and whether the business uses www. Either host style can be a deliberate choice; the repair is consistency. Confirm that the domain account and hosting settings are controlled by the business before requesting changes. Do not switch style simply because someone calls one option better for rankings.
Source checks: Google Search Central: Canonical URL methods · Google Search Central: Redirects and Search
Test a real path on each variant
Use a published service path rather than only /. Open the HTTP and HTTPS versions with and without www. Record the first response, each redirect destination, and the final page. A homepage-only check can miss a rule that sends every older deep link to the homepage, leaving visitors without the service they expected.
Check the secure connection as well as navigation
Have the technical reviewer verify that certificates cover the hosts visitors can request. A browser warning can occur before a redirect becomes useful to the visitor. Check whether the preferred HTTPS page redirects through an HTTP version or declares an HTTP canonical. A working visual page is not sufficient evidence that the path and protocol rules are coherent.
Align the four systems that publish URLs
Use one small test matrix for deployment.
- Set the supported host/protocol redirect rule with the correct permanent intent.
- Preserve the requested service path unless a separate page migration requires a mapped replacement.
- Use the preferred HTTPS host in canonical output.
- Update internal navigation and sitemap entries to the preferred version.
- Retest a second path and a genuinely nonexistent URL so broad rules do not hide errors.
Avoid repeated exceptions and global homepage redirects
A one-off repair for the example URL can leave the rest of the site inconsistent. Conversely, a broad rule that rewrites every request to / destroys meaningful page routing. Query strings may carry attribution or booking state, so test them deliberately. Keep host normalization separate from retiring a service page; they answer different questions.
Store a regression test for later platform changes
Save the four tested variants, final destination, and verification date in the website maintenance log. Repeat the check after changing DNS, proxy settings, SSL configuration, or hosting. Review current response behavior immediately and later search canonical evidence separately. Neither a clean redirect matrix nor a secure connection guarantees a particular search position.
Illustrative path lost during a host redirect
An illustrative business prefers https://www.example.com/roof-repair. The non-www HTTP request incorrectly lands on https://www.example.com/. The developer updates the host-normalization rule to retain /roof-repair, verifies the certificate, and retests another service. The repair restores a relevant destination for existing links; it does not establish that rankings have recovered.
The host matrix includes /roof-repair, /roof-inspection, and /not-a-real-service. The first two should preserve their relevant destinations, while the last should remain a genuine missing resource after any host normalization. This additional path check shows whether the rule repairs host consistency or simply replaces every request with the homepage. The reviewer also saves the intermediate statuses so a hidden protocol downgrade does not disappear from the final-page summary.
Four inputs, one intact service path
http://example.com/repair
Check redirect
https://example.com/repair
Check redirect
http://www.example.com/repair
Check redirect
https://www.example.com/repair
Preferred secure destination
Illustrative host test: preserve the service destination while normalizing host and protocol.
Your practical checklist
- Write one preferred secure host and service path.
- Test all four protocol/host combinations.
- Record redirect hops and final content.
- Verify certificates for requested hosts.
- Confirm canonicals and sitemap use the preferred host.
- Test another service and one missing URL.
Your next action
Test the four variants of a high-value service path and save the final destination from each.
Questions about this task
Is www better than non-www for SEO?
This test does not require either choice. Select the business's intended host and make the relevant technical signals and visitor routes consistent.
Why test a missing URL too?
A normalization rule should not turn every nonexistent path into a successful homepage response. A missing-page test exposes overly broad routing that a working service path can miss.
Sources and editorial notes
Prepared with AI-assisted research. Official sources are linked below; worked examples and checklists are Getting Found Local recommendations, not measured client outcomes.
Sources checked October 13, 2026. Platform interfaces and local resources may change; follow the current instructions on the linked official page.
How we research, illustrate, and update these guides · Suggest a correction