A pre-launch check has six stages: does the site work, is it legally covered, can search engines find it, can you measure it, does it look right when shared, and a final polish pass. Work through them in order — a flawless meta description on a page whose contact form silently fails is the wrong first fix.
Key takeaways
- Sequence beats a flat checklist. Whether the site works at all should be checked before whether its meta description is well written — both matter, but not equally, and not first.
- Test it the way a stranger would use it — click every link, submit every form with a real address, visit a URL that doesn't exist, open it on an actual phone.
- Most of the legal and discoverability items are one-time setup, not ongoing work — get them right once and they stay right.
- This isn't the SEO audit. That's a deeper, 22-point tool for after launch. This one is the minimum bar to publish responsibly.
- The tool below saves your progress in this browser, so a half-finished check isn't lost on a reload.
How to use this page
Work through the six stages in order below — each one assumes the stage before it already passed. Mark each item Done, Not yet, or N/A (not applicable to this site) in the tool. Every item links to its full explanation further down this page, including what to actually check and how to fix it if it's missing.
The pre-launch checklist tool
26 items, grouped the same way as the explanations below. Progress saves automatically in this browser.
Stage 1 — Does it actually work
Before anything else, the site has to function the way a visitor expects. This is the stage most builders skip because they've only ever used the site as its own author — logged in, on a fast connection, on the device it was built on.
1. Every link actually goes somewhere real
A dead internal link is the fastest way to make a new site look abandoned. Click through the whole navigation, every footer link, and every link inside your actual content — don't just trust that they're right because you wrote them correctly once.
What to check: every nav item, footer link, and in-content link resolves to a real page, not a 404 or a placeholder. A free crawler tool (Screaming Frog's free tier covers small sites) can do this faster than clicking manually once the site has more than a handful of pages.
How to fix it: fix or remove the broken link, or point it at the correct page. If a planned page genuinely isn't ready, don't link to it yet rather than linking to a placeholder.
2. Every form actually submits, and the reply lands where you'll see it
A broken contact form is invisible to you until someone tells you it didn't work — and most people who hit a broken form simply leave instead of telling you.
What to check: submit every form on the site yourself, with a real email address, and confirm the submission actually arrives — in your inbox, your CRM, wherever it's supposed to go. Check your spam folder specifically; this is the single most common way a "working" form quietly fails.
How to fix it: if the submission doesn't arrive, check the form handler's configuration and the receiving email's spam filtering before assuming the form itself is broken — the two most common failures are a misconfigured "from" address and an email landing in spam because it failed an authentication check.
3. A broken URL shows a real 404 page, not a blank screen
Visitors mistype URLs and follow old links from other sites constantly. What they see when that happens is either a small recovery moment or the point where they give up entirely.
What to check: visit a URL on your domain that doesn't exist. Does it show a page explaining that, with a way back to real content — or your host's own generic error page, or nothing at all?
How to fix it: build a custom 404 page with a clear message, a search box or links to main sections, and wire it up via your host's error-document setting. This site's own 404 page is built exactly this way, as a working example rather than a hypothetical.
4. It's been tested on an actual phone, not a resized browser window
A resized desktop browser is not the same test as a real phone — real devices have different rendering quirks, real touch targets, real network conditions, and real autofill/keyboard behavior that a simulator doesn't fully reproduce.
What to check: open the live site on a real phone (yours, or a friend's running a different OS) and click through the main paths — homepage to contact, homepage to your main offer page, any form.
How to fix it: fix whatever breaks specifically on the real device — often tap targets, viewport sizing, or a sticky element covering content differently than it did in a browser's device emulator.
Stage 2 — Legal and trust basics
Once the site works, the next question is whether it's honest about who runs it and what it does with a visitor's information. None of this is legal advice — requirements vary by where your visitors are, and a real business handling real customer data should get actual legal review, not a checklist item.
5. Privacy policy page
What to check: a page explaining what data the site collects (forms, analytics, cookies) and what happens to it, linked from the footer.
How to fix it: write one or use a reputable generator as a starting point, but read and edit it to actually match what the site does — a privacy policy describing data practices the site doesn't actually follow is its own problem.
6. Terms of service page
What to check: a page covering acceptable use, liability, and the basic rules of using the site or buying from it, if applicable.
How to fix it: same approach as the privacy policy — a template is a reasonable start, but it needs to actually describe this specific site.
7. Real, accurate contact information
What to check: an email address or phone number that's actually monitored, not a placeholder left over from a template.
How to fix it: replace any placeholder contact details and test that they actually reach someone.
8. Cookie consent, if the site actually uses tracking cookies
This only applies if the site sets cookies for analytics, advertising, or similar tracking — a site with no tracking at all generally doesn't need a consent banner for that reason alone, though other local requirements may still apply.
What to check: if analytics or ad-tracking scripts are running, is there a consent mechanism before they fire, appropriate to where your visitors are located?
How to fix it: add a consent tool that actually blocks tracking scripts until consent is given, not just a banner that displays alongside scripts that were already running.
9. A clear call to action on every page that needs one
What to check: on any page meant to lead somewhere — book a call, buy, subscribe, contact — is there one obvious next step, not three competing ones or none at all?
How to fix it: pick the single most important action per page and make it the visually dominant one.
Stage 3 — Can anyone find it
This is the minimum bar for being discoverable at all — not full SEO (that's a separate, ongoing tool below), just making sure nothing is actively blocking or confusing search engines from the start.
10. robots.txt allows crawling
What to check: visit yourdomain.com/robots.txt and confirm it doesn't contain a blanket Disallow: / — a surprisingly common leftover from a staging site that never got removed.
How to fix it: remove any accidental disallow rule before launch. See the noindex vs. robots.txt guide for how this specific mistake can lock a page out of search for a long time if caught late.
11. XML sitemap exists and is submitted
What to check: a sitemap.xml listing your real pages, submitted in Google Search Console once it's verified (stage 4, below).
How to fix it: generate one (most site builders and frameworks can do this automatically) and submit it in Search Console.
12. Every page has a unique title tag
What to check: no two pages share a title, and no page is missing one.
How to fix it: write a specific title per page. The SEO audit checklist covers title-tag length and structure in more depth once the site is live.
13. Every page has its own meta description
What to check: a unique meta description per page, not the same boilerplate copied everywhere.
How to fix it: write one to two sentences per page describing what's actually on it.
14. Canonical URLs are set
What to check: each page declares itself as its own canonical URL, especially if the site is reachable at more than one address (with and without www, for example).
How to fix it: add a self-referencing canonical tag site-wide, and redirect duplicate address versions to one preferred form.
15. Favicon shows up correctly
What to check: the small icon appears in the browser tab, in bookmarks, and when the site is added to a phone's home screen.
How to fix it: add a proper favicon set (multiple sizes cover more devices reliably than a single file) and confirm it renders rather than assuming the file upload worked.
Stage 4 — Can you measure anything
Everything after launch is a guess without this stage done first.
16. Analytics installed and verified
What to check: load the live site in another tab and confirm a visit actually registers in your analytics tool in real time.
How to fix it: fix the install (a mistyped tracking ID is the most common cause) before launch, not after wondering why traffic shows zero.
17. Google Search Console verified
What to check: domain or URL-prefix ownership verified, with the sitemap from stage 3 submitted.
How to fix it: complete verification via DNS record or HTML file upload, whichever your host supports more easily.
Stage 5 — Does it look right when shared
18. The link shows a real preview when shared
Paste the homepage URL into a Slack message, a WhatsApp chat, or a tweet draft without sending it — most of these platforms show a preview card using the page's Open Graph tags. A missing or wrong image/title here is one of the most visible "this looks unfinished" signals a new site can send.
What to check: does the preview card show the right title, description and image — not a blank box, the wrong logo, or placeholder text?
How to fix it: add og:title, og:description and og:image meta tags (and their Twitter Card equivalents) to the page head, with an image sized for social previews, typically around 1200×630px.
Stage 6 — Final polish pass
Everything here is real and worth doing, but none of it matters if stages 1-5 aren't already solid — this is the pass that turns "it works" into "it's good."
19. Every meaningful image has alt text
What to check: descriptive alt text on content images; empty alt text (alt="") on purely decorative ones, which tells screen readers to skip them rather than describe them.
How to fix it: write specific descriptions, not generic filler like "image" or the bare filename.
20. Basic accessibility checks pass
What to check: colour contrast, keyboard-only navigation through the main paths, and tap targets that aren't too small or too close together.
How to fix it: an automated scanner catches some of this but misses most real issues — see the automated accessibility testing guide for why a scanner alone isn't enough, and what a manual keyboard pass actually catches that it doesn't.
21. Page loading speed has actually been measured
What to check: run the live homepage and your main page through PageSpeed Insights rather than assuming it's fast because it felt fast on your own fast connection.
How to fix it: slow hosting is frequently the floor everything else sits on — the hosting pillar guide covers choosing infrastructure that doesn't fight page speed from the start.
22. The real questions people would ask are actually answered
What to check: does the site answer the specific questions a visitor would have before contacting or buying — not generic filler questions invented to pad a page.
How to fix it: write down the three questions you're actually asked most often in person or by email, and answer them directly on the site.
23. A test submission's reply doesn't land in spam
This is distinct from item 2 (does the form submit at all) — this checks whether your own reply back to a customer reliably reaches them.
What to check: send a real test email from the address your forms or orders would reply from, to an account you don't normally use, and check whether it lands in the inbox or spam.
How to fix it: this is usually an SPF/DKIM/DMARC authentication gap on the sending domain — the business email migration guide covers the same authentication records in the context of switching providers.
24. Proofread by someone other than you
What to check: have at least one other person read every page — typos and awkward phrasing are much harder to catch in your own writing than someone else's.
How to fix it: fix what they find. This is cheap and fast compared to everything else on this list, and skipped surprisingly often.
25. It looks and works the same in a private window
Testing only while logged into your own CMS, with your own cached assets and cookies, can hide problems a first-time, logged-out visitor would actually hit.
What to check: open the live site in a private/incognito browser window and click through the same main paths again.
How to fix it: anything that breaks specifically here is usually a caching or login-state bug — clear the relevant cache or fix the logic that assumed a logged-in session.
26. Someone who's never seen the site has clicked through it once
This is the actual final gate, not a formality — a person seeing the site for the first time will click things in an order you never would, because you already know where everything is.
What to check: hand the live link to someone who's never seen it, with no instructions, and watch (or ask) where they get confused or stuck.
How to fix it: fix whatever actually confused them, not what you assumed would.