Web operations
Website launch checklist: verify the public path, not just the homepage
A practical pre-launch sequence for DNS, HTTPS, redirects, crawl controls, sitemaps, metadata, errors and mobile usability.
In short
A homepage loading on one laptop is not a launch test. A reliable release verifies the public hostname, response chain, representative routes, crawler instructions, metadata and recovery path from outside the development environment.
- Test the final public hostname from a clean client.
- Keep redirects short, intentional and free of loops.
- Make robots.txt and sitemap agree with the URLs you want indexed.
- Check representative content, error and localized routes—not only `/`.
- Record rollback steps before changing traffic.
1. Define the release contract
List the public hostnames, canonical scheme, base path, supported languages and representative routes. Include a content page, interactive tool, legal page, static asset, 404 and any important redirect.
Write the expected result for each route: final URL, status code, page marker and whether it should be indexed. A release check is actionable only when “correct” is explicit.
- Primary and alternate hostnames listed
- Canonical HTTPS URL decided
- Representative routes selected
- Rollback owner and trigger recorded
2. Verify DNS, TLS and the response chain
Resolve the public hostname using independent resolvers, then connect over HTTPS. Confirm the certificate covers the hostname, is currently valid and serves the intended application.
Follow redirects without browser cache. HTTP-to-HTTPS and alternate-host redirects should reach one canonical destination. Long chains waste time and create more failure points; loops or mixed destinations must block the release.
3. Align crawl controls and discovery
Fetch robots.txt exactly where crawlers will request it. Confirm it does not block required pages or critical assets and that any sitemap reference points to a reachable, current file.
A sitemap is a discovery hint, not a quality certificate. Include canonical URLs that you want in search, omit private or duplicate paths, and make every important URL reachable through normal internal links as well.
- robots.txt returns 200
- Sitemap references are reachable
- Sitemap URLs are canonical and return 200
- No accidental noindex on public content
4. Inspect rendered pages as users and crawlers receive them
For each representative route, verify one clear H1, useful title and description, canonical URL, language metadata, visible main content and working internal links. Localized pages should point only to real reciprocal translations.
Test mobile width, keyboard focus, form labels, validation messages and horizontal overflow. Confirm the core free task works without signup. Error states should explain the next step instead of exposing stack traces or empty panels.
5. Observe, roll back and re-check
After publication, run the same checks against the live origin and inspect server or application errors. Compare the deployed asset or release identifier with the intended commit so a green test is tied to the right version.
Rollback when a critical route, certificate, canonical path, data boundary or core action fails. After recovery, repeat the public checks; do not assume reverting files also reverted caches, routing or DNS.
Next step
Check your own case
Frequently asked questions
Is a 200 response enough?
No. A generic fallback or error page can return 200. Check the final URL, expected page marker, metadata and core action.
Should every URL appear in the sitemap?
No. Include canonical URLs you want discovered and indexed. Navigation must still link important pages.
Can robots.txt remove a page from search?
Blocking crawl does not reliably remove an already known URL. Use the appropriate indexing control and follow current search-engine guidance.
When should a launch be rolled back?
When the core public path, security boundary, canonical routing or essential user task is broken and a quick, well-understood fix is not safer than rollback.
Primary sources and reference
Sources consulted during editorial review. External links open the organization responsible for the standard or guidance.