A launch is not complete because a homepage loads in one browser. A public site can look correct while returning the wrong status code, redirecting inconsistently, exposing an expired certificate, or leaving crawlers without a usable sitemap. This checklist is for a small, deliberate verification pass after a launch, migration, redesign, or important routing change.
Start with one canonical public URL
Write down the one URL you expect people and search engines to use: typically https://example.com/ or https://www.example.com/. Then test the common alternatives: HTTP, HTTPS, www, non-www, and an intentionally mixed-case or trailing-slash version where relevant. The goal is not to force every URL to return 200. The goal is for alternate versions to reach the chosen address through a predictable redirect.
Use the Redirect Checker to record the complete chain. A clean result normally has one permanent redirect from the alternate address to the canonical address, followed by a 200 response. Multiple hops make troubleshooting harder, slow down visitors, and can preserve old routing mistakes. A chain that reaches a login page, a temporary redirect, or a different hostname needs an intentional explanation before launch.
Check important status codes individually
Next, test the homepage and a small sample of representative pages: a main category, one current article, a utility page, a contact page, and a deliberately missing URL. The HTTP Status Code Checker is useful when the question is simply, “What did this public URL return?”
- 200 should mean a useful public page is available.
- 301 or 308 should have a clear permanent destination when an old page moved.
- 302 or 307 should be temporary for a reason, not a leftover deployment default.
- 404 or 410 is appropriate for content that truly no longer exists; do not send it to an unrelated homepage just to avoid a visible error.
- 500-series responses are server failures and should block publication until understood.
Status codes are not a quality score. They are evidence of what the server actually told a visitor or crawler at that moment. Record the tested URL, response code, final destination, and date. That small record prevents later debates based on what the page “seemed” to do in a browser.
Inspect the first response headers
Headers reveal information that page screenshots do not: the final status, redirect target, cache rules, content type, canonical hints supplied as headers, and security controls. Paste a captured response into the HTTP Headers Parser when you need to isolate these values from a raw response.
For a public HTML page, confirm that the content type is HTML and that the response does not accidentally block indexing with an X-Robots-Tag: noindex. For HTTPS pages, use the Security Headers Auditor as a starting point to review whether expected browser-facing headers are present. A missing header is not automatically a vulnerability; its relevance depends on the application, but unexplained changes are worth investigating.
Confirm the canonical and crawl path agree
Each indexable page should have a clear preferred URL. On HTML pages this is usually expressed with a canonical link element. The Canonical URL Generator can help construct a correctly formatted tag, but it cannot decide which URL is the right one for your site. That decision comes from your routing, internal links, redirects, and content strategy.
Also open /robots.txt and /sitemap.xml directly in a private browser window. A robots file should not accidentally disallow the public sections you expect search engines to crawl. A sitemap should contain only canonical, public URLs that return useful content. The robots.txt Generator and Sitemap Visualizer are drafting and review aids, not substitutes for checking the live files.
Review TLS and the public certificate
HTTPS is more than a padlock icon. Test the public hostname with the SSL Checker and check the certificate name, expiration, and issuing chain. If a redirect sends visitors from one hostname to another, test both. A certificate that is valid for the final address but not for the first address can still produce a failed experience before the redirect occurs.
A minimal launch record
For each release, keep a small checklist with the canonical URL, test date, expected result, actual result, and owner. Include the redirect chain, status for a few important URLs, robots and sitemap checks, and any known exceptions. This turns routine website maintenance into a repeatable process instead of a series of guesses.
For implementation details about crawling and sitemaps, refer to Google Search Central’s crawling and indexing documentation. This guide explains a practical verification workflow; it does not guarantee indexing or ranking.
Test the paths people actually use
A homepage-only check misses many launch failures. Build a short test set from real routes: a page shared in an email campaign, one high-traffic landing page, a product or tool page, a downloadable asset, a contact path, and the old URL of anything moved during the release. Include one URL with a query parameter when analytics or campaign links use them. The expected result may differ by route, but it should be written down before testing.
Internal links deserve a separate pass. Click navigation, footer, contextual links, buttons, and the logo from a normal visitor session. A link can look correct in a CMS entry while resolving to a staging hostname, an obsolete slug, a duplicate URL, or a file that no longer exists. For a focused release, inspect the links added or changed in that release rather than trying to manually browse an entire large site.
Separate redirect intent from redirect accidents
Redirects are useful when they preserve a clear relationship between an old resource and its replacement. They are poor substitutes for a missing-content strategy. Sending every deleted URL to the homepage can confuse visitors because the destination does not answer the original request. A better choice may be a relevant replacement page, a useful category page, or an honest 404 or 410 response when there is no equivalent.
Watch for redirect loops and protocol disagreements. A common failure pattern is an application that redirects HTTP to HTTPS while a proxy or CDN redirects HTTPS back to HTTP. Another is a host-level rule that forces www while the application forces non-www. Test a chain from the exact external URL, not only from a local development address. If the chain has more than one deliberate hop, document why each hop exists and remove legacy rules that no longer serve visitors.
Review what a crawler can actually receive
Browser rendering is only part of the picture. A public page should return useful server-rendered HTML or otherwise provide a reliable rendered result to crawlers. View source, not just the visual page, to confirm that the title, description, canonical reference, main heading, and meaningful content are present. If important content appears only after an authenticated request, a user interaction, or an API request that fails for unfamiliar clients, treat that as a launch risk.
Do not use this as a reason to block useful client-side features. It is a reminder to check the public baseline. Use a normal browser, a private window, and a crawler-style HTTP request when troubleshooting differs between environments. Differences can point to caching, authentication, bot protection, geo routing, or deployment configuration rather than a content problem.
Include performance and accessibility in the release conversation
Technical correctness includes whether people can use the page. Check the changed page on a narrow viewport, keyboard-navigate the important controls, and verify visible focus, readable contrast, descriptive link text, and form labels. A page that technically loads but traps keyboard users or hides a key action behind an unreadable control is not ready for a public audience.
For performance, compare the page before and after a meaningful change when possible. Large images, third-party scripts, font changes, and client-side libraries can change the experience even when the response code remains 200. Record the reason for an exception rather than accepting unexplained regressions. A small release note that names known tradeoffs is more useful than a blanket claim that a site is “fully optimized.”
Decide when the check is complete
End the pass by assigning any unresolved item an owner and a next action. The goal is not a perfect spreadsheet; it is a reliable handoff. A release can be ready with documented, low-risk follow-up work. It is not ready when a public URL has unknown behavior, a critical route fails, or the team has no way to tell whether the intended version is live. Repeating this small process after each significant deployment builds a more trustworthy site over time.
Turn findings into a useful maintenance record
Use the results to improve the site, not merely to pass a one-time review. If a redirect chain exposed an old campaign URL, update the campaign documentation and internal links. If a test found a weak page title or missing description, correct the template or page entry that produced it. If a crawler response differed from a normal visitor response, preserve the request details so the issue can be reproduced after the next deployment.
A short release record can include the release identifier, URLs tested, expected status, observed status, redirect destination, person responsible, and resolution date. For recurring changes, add a link to the relevant deploy or issue. This makes a site easier to operate because later reviewers can distinguish a known, accepted exception from a regression introduced by a new release.
When to seek a deeper technical review
Escalate when a public page behaves differently by location, device, login state, or user agent; when a certificate warning appears; when a redirect crosses unexpected domains; or when a page is reachable but the application returns incorrect content. These issues often involve CDN settings, host rules, application routing, or security controls that cannot be resolved by changing a single page. The appropriate response is to collect evidence, reduce the change to a reproducible case, and involve the person responsible for that layer.