Website Launch Checklist: 21 Checks That Catch Hidden Failures

A launch announcement can make a website feel finished. But a working homepage proves only one thing: that the homepage loaded at least once. It does not prove that a contact form delivers enquiries, a blog can read its database, a screenshot resolves to an actual image, or Google can discover a new article. This checklist is for the awkward stage after a site looks ready but before you trust it with customers.

We prepared this guide while reviewing Oyeola Online's own editorial rollout. The preview database contained published test records, while the production-named database had no published blog entries. The hosting dashboard showed a database URL assigned to a preview branch, not production. Those are concrete differences a visual design review would not reveal. This is a documented configuration audit, not a claim that the live production problems have already been resolved.

What the launch checklist actually tests

Think in five layers: access, content, conversion, discoverability and operations. Testing only one layer creates false confidence. Each item below gives you a condition that can pass or fail and a piece of evidence worth recording.

Layer 1: Access and routing — checks 1–4

1. 1. Open the canonical homepage with and without www. Confirm both versions resolve consistently to the intended canonical address.
2. 2. Confirm the browser reports a valid HTTPS connection without mixed-content warnings on important pages.
3. 3. Open direct URLs to at least three deep pages, not just links from the homepage. Refresh each page to detect routing failures.
4. 4. Visit a deliberately nonexistent URL. Confirm visitors get a useful 404 response rather than an unrelated page with HTTP 200.

Why these matter: search engines and customers arrive on individual URLs. A navigation link working in one session does not mean a shared link will load in another browser.

Layer 2: Real content and media — checks 5–8

1. 5. Confirm every article visible in the editor exists in the correct database and has a deliberate publication status.
2. 6. Check the public blog listing against the database: it should show published articles only, not drafts or deleted posts.
3. 7. Open every cover image and major project screenshot directly in a fresh browser tab. Broken file paths are easy to miss behind decorative placeholders.
4. 8. Follow at least two internal links from an article to another relevant article or service page; confirm their destinations and anchor labels.

An especially useful test is to compare the article count returned by your public API with the cards rendered on /blog. If the API fails, show a specific recovery message; presenting a perfectly styled empty grid conceals the underlying outage.

Layer 3: Enquiries and customer journeys — checks 9–12

1. 9. Submit the contact form using test details and verify that the server accepts the request.
2. 10. Confirm the submission actually reaches the correct recipient or CRM, rather than trusting the green success notification.
3. 11. Try the primary call to action from the homepage, a service page and a case study. Record each destination and its next step.
4. 12. Test validation and error messages: empty required fields, malformed emails and a temporary network interruption should not silently lose work.

A website can have excellent typography and still fail commercially if an enquiry vanishes. The two-part test is essential: user-facing confirmation and back-office delivery are different events.

Layer 4: Search visibility — checks 13–16

1. 13. Check robots.txt and page-level robots rules. Your private admin portal should stay private; public articles need the appropriate indexability settings.
2. 14. Open the sitemap URL and verify it contains live, canonical article URLs rather than drafts or stale links.
3. 15. Inspect a published article's raw HTML for a unique title, description, canonical, H1 and meaningful content; do not rely entirely on JavaScript rendering.
4. 16. Use Google's URL Inspection tool to see whether the page can be accessed and indexed. Sitemap submission is a discovery hint, not an indexing guarantee.

The distinction between a URL being published, crawled and indexed matters. A Search Console submission confirmation is not evidence that the page already appears in search.

Layer 5: Operations and ownership — checks 17–21

1. 17. Confirm production and preview deployments point to the intended databases, not merely to a similarly named environment variable.
2. 18. Verify that editor, author and owner roles have the correct permissions for drafts, approvals, publishing and deletion.
3. 19. Record who can restore the content and where the database backup or recovery procedure lives.
4. 20. Repeat key tasks on a narrow phone screen and with keyboard navigation. Test tables and images at mobile widths.
5. 21. Make one safe, reversible update and verify it appears only in the intended environment. Record the deployment URL and revision.

A compact test-evidence matrix

How to use this without turning it into bureaucracy

Use a shared sheet with four columns: URL or feature, expected result, observed result, and screenshot or request identifier. Assign an owner to every failed check. Avoid marking an item passed because a colleague says it worked yesterday; note the date, device and environment tested.

For a small website, running all 21 checks before a release is manageable. For a larger site, turn the highest-risk tests into automated smoke checks and keep human attention on content accuracy, visual presentation and real customer journeys.

The useful question at launch is not, 'Does it look complete?' It is, 'What evidence would convince us the important parts work?'

What to test first on your own website

Start with one high-value journey: find a relevant service page through search, read its case study, send an enquiry, and confirm delivery. Then repeat with a public blog article and its cover image. If any link in that chain breaks, fix the handoff before investing more in promotion.

Further reading: Google Search Central, 'Get started with Search: a developer's guide' (developers.google.com/search/docs/fundamentals/get-started-developers); Vercel, 'Environment Variables' (vercel.com/docs/environment-variables). This article is an operational checklist, not a report of benchmark scores or promised search rankings.