Website launch checklist

This is a generic checklist of things to check before deploying any public-facing website.

The below list is inspired by this episode of the Syntax FM podcast.

Automated robot checkers:

• Lighthouse - can be launched via Chrome developer tools

• SEO checkers/audits, to make sure all the major SEO tags and metadata is filled on all pages

• Accessibility checks, such as axe, to make sure all the buttons, links, images etc. have correct accessibility metadata. Also checks for sufficient contrast on all items, to make sure the page can be seen and read by people with non-ideal vision.

Build tools & performance:

• Code splitting: make sure the code bundles are minified and split, i.e. only parts of the code that are required are loaded

• Use PageSpeed Insights to check website's performance

• If a service workers are used, make sure to disable it on launch to prevent the end user caching the website for a long time. The SW should be enabled once the website is stable and no more fixes/patches are expected

Compatibility:

• Test the website on all browsers that we expect to support. Ask all employees to check the website on all of their devices

Content:

• Check spelling and grammar. Make sure multiple people go through the texts on all pages. Make sure there is no placeholder text (lorem ipsum etc.)

• A working 404 page. Make sure it exists and looks acceptable

Accessibility (in addition to the robot checkers):

• Correct tab order. Use the site with keyboard only and make sure it’s a good experience. Tab order should make sense and not jump around the page unpredictably

SEO (in addition to the robot checkers):

• Sitemap created and uploaded to Google Webmaster Tools

• Correct heading hierarchy. Every page should have no more than one H1 tag, and any lower tags should be preceded by a higher order tag (no H3 directly under H1)

Analytics:

• Google analytics

• Facebook tracking pixel

• Any other analytics platforms should be initialized (such as drip)

Server config & access:

• .htaccess, if applicable

• Redirects where needed

• robots.txt, configure where and what the crawlers should have access to

• Enable GZIP compression on the server

• Caching, Cloudflare or other CDN, especially on all static pages

Other generic points and pitfalls:

• Make sure tests are passing

• Git issues are closed

• Merge pull requests

• Write documentation on processes (readme, etc.)

• Deploy to staging environment and test production build

• No unwanted logs or errors left in production build

• Check TODO: comments in the code

• DNS Propagation

Need help with deployment automation or launch readiness? Our development team can assist.

Frequently Asked Questions

What should I check before launching a website?

Run Lighthouse and accessibility audits (axe), verify SEO metadata on all pages, test on all target browsers and devices, check for placeholder content, confirm 404 page works, validate heading hierarchy (one H1 per page), set up analytics (GA4, tracking pixels), configure robots.txt and sitemap, enable GZIP compression, and deploy to staging first for a final production build test.

Why should I disable service workers at launch?

Service workers cache your site aggressively in users' browsers. If you launch with a service worker enabled and then need to fix a bug, users may continue seeing the cached (broken) version. Disable service workers until the site is stable and no more rapid patches are expected. Enable them once the site has settled to improve load performance.

What are the most common website launch mistakes?

Forgetting to set up redirects from old URLs (killing SEO), leaving placeholder text or broken links, not testing on mobile devices, missing analytics setup, skipping accessibility checks, and deploying without a staging environment test. Each of these is easy to prevent with a pre-launch checklist but expensive to fix after users see the site.

How do I check website performance before launch?

Use Google PageSpeed Insights to measure Core Web Vitals — Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. Verify code bundles are minified and split so only required code loads per page. Check that images are optimized and served via a CDN. Test with throttled network connections to simulate real-world conditions.

Related Reading

• Minimal Sphinx configuration to play with Sphinx
• Announcing DokuWiki Sphinx Search Plugin
• Common Challenges Faced When Implementing Kubernetes and How to Overcome Them