Pre-Publish Website Checklist: A Practical Review Before Going Live

Start with the visitor journey

Open the site in a private browser window and complete the most important journey as a normal visitor. Read a key page, submit a test enquiry, create an account or complete another permitted test. This confirms that the public experience does not depend on an old login, cached data or a developer-only setting.

Check both desktop and mobile layouts. A page can look correct in one browser while a menu, form field or important button is unavailable on a smaller screen.

• Confirm primary navigation reaches the intended pages.
• Test the main contact, sign-up or purchase journey.
• Check error and success messages are understandable.
• Make sure contact details, prices and policy links are current.

Choose one preferred public URL

Choose one public version of the site address and use it consistently. The canonical tag, internal links, sitemap and redirects should point to the same HTTPS version. Competing www, non-www, HTTP or duplicate path versions make maintenance and indexing harder to reason about.

A redirect is useful when it sends a visitor directly to the preferred page. Long chains and loops add delay and can hide configuration mistakes.

Make content and discovery intentional

Every important page needs a clear purpose. Give it a descriptive heading, a useful title and a concise description that matches what a visitor will actually find. Avoid publishing placeholder pages, duplicated descriptions or pages created only to target a phrase.

Link important pages from normal navigation or relevant content. A sitemap supports discovery, but it does not replace meaningful internal links and genuinely useful information.

• Remove test pages, empty categories and unfinished public pages.
• Review titles and headings for accuracy rather than keyword repetition.
• Confirm robots rules allow the pages you want indexed.
• Include preferred URLs in the XML sitemap.

Review browser-facing security

Confirm that the public site uses HTTPS, presents the expected certificate and does not send visitors through an insecure version of a sensitive page. Security headers and cookie settings should be tested with the application, because an overly strict setting can break legitimate scripts or sign-in flows.

A public review is not a penetration test. It cannot assess private code, cloud permissions, administrator accounts or internal networks. Use it to identify public configuration that deserves follow-up.

Set a maintenance date before launch

Record what changed, who owns the site and when the next review will happen. This prevents launch settings from becoming permanent assumptions. Review forms, certificates, analytics, policy pages, backups and third-party integrations on a regular schedule.

When a result changes after launch, compare it with the recorded baseline. A controlled change and a clear test make troubleshooting faster than trying several changes at once.