Write down the intended hostname policy
Choose the approved public hostname for this audit, for example https://example.com. Document whether www is an alternate entry point and identify subdomains that have separate purposes. A customer portal or asset hostname should not be included in a broad redirect rule merely because it shares the same parent domain.
This procedure validates a hostname consolidation already chosen by the site owner. It does not require changing a working hostname for cosmetic reasons. Keep the content and page paths stable during the test so that a failed check can be traced to hostname handling rather than an unrelated redesign.
Build a matrix of entry points and page types
For each representative path, test HTTP and HTTPS on both the www and non-www host. Include the homepage, a service page, an article, an Arabic page and a downloadable file where applicable. Add one deliberately nonexistent path to detect rules that silently send every request to the homepage.
Record the requested address, first response, any redirect destination, final address and expected content. Test HTTPS entry points without bypassing certificate errors: a visitor must establish the secure connection before receiving an HTTP redirect. A working preferred hostname does not establish that the alternate HTTPS hostname has a valid certificate.
Look for disagreements between configuration layers
If www redirects to the bare host but the application redirects back, capture both responses and assign the conflicting rules to their owners. Review the CDN, web server and application configuration together. Avoid repeatedly adding new redirect rules without identifying which existing rule produced the return journey.
Once each entry point reaches the intended page, compare its canonical address, language alternates, internal links and sitemap entries with the approved hostname. Google's migration guidance calls for updating these references to the new URLs and mapping old addresses to their corresponding destinations. Treat a successful browser load as one check, not the entire acceptance test.
Worked example: one hostname, several outcomes
In an illustrative test, https://www.example.com/en/services/ reaches https://example.com/en/services/ correctly, while the Arabic equivalent lands on the English homepage. The homepage test passes, but the consolidation is incomplete because the second route loses both the requested page and its language. Record that row as a failure even if the final response is 200.
A separate test of /missing-review-page/ returns the homepage too. Investigate whether an overbroad fallback is hiding nonexistent paths. Correct the rules using the agreed path mapping, then repeat every row affected by that configuration. Do not change the site's real content merely to make the matrix appear green; the expected outcome must reflect whether each page actually exists.
Define completion and retain a recovery path
Before changing production rules, save the current configuration and identify how to restore it. After deployment, retest from a fresh browser session and an HTTP inspection tool. Check a real navigation journey in each language, including a download or contact route if it belongs to the public site. Investigate stale cached behavior before making another configuration change.
Save the completed matrix with timestamps, exceptions and the responsible owner. Add unresolved rows to your website-audit action list. Continue observing search data separately: a consistent hostname configuration is a technical result, whereas search-engine processing happens later. Do not report a ranking improvement or completed reindexing solely because the redirect tests passed.