Before a website goes live, run this launch checklist in order: prove every form delivers, check the site on a real phone, confirm Google can index it, set redirects from any old URLs, and verify backups and analytics work. Most launch-day disasters are boring — an enquiry form emailing a dead inbox, a 'coming soon' block left on indexing, a site with no backup — and every one of them is caught by an unglamorous hour of checking.
This checklist is the distilled version of what experienced teams run before flipping the switch, organised so a small business owner can work through it without a technical background. It assumes a new site or a redesign replacing an old one. If you want it as a printable document you can tick off at your desk, the shop's WordPress Business Website Launch Checklist is exactly that — this article is the full method behind it.
Content and Proofreading Checks (1–7)
1) Read every page aloud once — typos hide from eyes and confess to ears. 2) No placeholder text, lorem ipsum or 'TODO' survives anywhere, including footers and error pages. 3) Contact details are identical everywhere: phone, email, address, opening hours — and match your Google Business Profile. 4) Prices, service areas and claims are current; nothing promises what the business no longer offers. 5) Every image has alt text that describes it for someone who cannot see it. 6) Links all resolve — click every menu item, button and footer link; one 404 on launch day is a visitor lost. 7) Spelling of names, places and your own business name is consistent, including in page titles.
Forms, Email and Conversion Checks (8–13)
8) Submit every form yourself — contact, quote, booking, newsletter — and confirm the message arrives in the right inbox, not just that the site says 'thank you'. 9) Check the spam folder too; form notifications landing in spam is a silent business leak. 10) Test the thank-you page and any auto-reply email the visitor receives. 11) Click every phone number on a phone — it should dial. 12) Test online payments with a real small transaction if you sell anything. 13) Confirm enquiry notifications go to an inbox a human checks daily, not a legacy address. If your launch follows a build project, cross-check timing expectations against the realistic website timeline — launch checks belong in the schedule, not after it.
Where launch problems are usually found, by checklist area (illustrative share, %) — hover or tap each bar for details.
Mobile, Speed and Technical Checks (14–20)
14) Browse the whole site on your own phone: menus open, text is readable without zooming, buttons are tappable, nothing overflows sideways. 15) Test on the other platform too (borrow an iPhone if you are Android, and vice versa). 16) Run the homepage and one inner page through a speed test on a mobile connection profile; images are the usual culprit — the workflow for compressing images without losing quality fixes that before launch, not after. 17) The site works in private/incognito mode — no cookie-dependent breakage. 18) HTTPS padlock shows on every page with no mixed-content warnings. 19) The 404 page is friendly and links home. 20) Favicons and social-share images are set, so links shared on WhatsApp and social media show your branding, not a grey box.
SEO and Analytics Checks (21–27)
21) Search engines are allowed to index the site — the single most expensive launch mistake is a leftover 'discourage search engines' setting from development. 22) Every page has a unique title and meta description (the small business SEO checklist covers what good looks like). 23) The XML sitemap exists and is submitted in Google Search Console. 24) If this replaces an old site: every old URL that had traffic or links redirects to its new equivalent — build the redirect list before launch day from the old sitemap. 25) Analytics (for example GA4) is installed and you can see your own test visit in real-time reports. 26) Search Console ownership is verified for the business, not a developer's personal account. 27) One canonical domain is chosen — www or not, http redirects to https — and every variant lands on it.
| Check | How to verify in 2 minutes | Cost if missed |
|---|---|---|
| Forms deliver | Submit each form; watch the inbox | Lost enquiries from day one |
| Indexing allowed | Search Console URL inspection | Invisible on Google for weeks |
| Redirects from old URLs | Open 3 old bookmarks | Rankings and backlinks lost |
| Backups running | See a completed backup in the dashboard | No recovery after any incident |
| Analytics live | Real-time report shows your visit | Launch performance unmeasurable |
Redirects: The Pre-Launch Work Most Redesigns Skip
Check 24 fits in one line; doing it properly is an afternoon. A redirect map is simply a two-column list — every old URL on the left, its new home on the right — and it is the difference between a relaunch that keeps its rankings and one that starts over. Build it before launch day in three passes. First, inventory: pull the old site's sitemap and its full page list from the CMS; add any URL Search Console shows with impressions or clicks in the last quarter, because those are proven valuable. Second, map honestly: each old page goes to its true equivalent on the new site — the same service, the same topic. Sending everything to the homepage is the lazy version and search engines treat it as a soft error page, because it is one. Third, test after launch: open a sample of old bookmarks and links — especially any printed on vehicles, leaflets and directories — and confirm each lands somewhere sensible, in one hop, with no redirect chains.
Keep the map file. Six months later, when someone asks why an old link behaves oddly, the map is the answer — and it doubles as documentation of what the old site contained.
Legal, Security and Ownership Checks (28–32)
28) Legal pages exist and name the real business: privacy policy, terms, and cookie consent where your region requires it (the EU/UK/Spain rules are stricter than the US baseline). 29) A backup has run successfully at least once and you know where restores live. 30) Admin accounts are individual, with strong passwords and two-factor where offered — and the business owns the master accounts for domain, hosting and analytics. 31) Software, themes and plugins are updated to current versions on day one. 32) Someone has written down: where the site is hosted, when the domain renews, and who to call when it breaks. If that last item sounds trivial, you have never watched a business discover its domain expired.
None of these checks require deep skill; they require a list, an hour and honesty. Which is why the list exists — memory is not a launch process. For the printable, tick-box version with space for notes per check, the launch checklist in the shop mirrors this article check for check.
The Staging-to-Live Gap: Why Passed Tests Fail on Launch Day
Everything passed on the staging copy, yet launch day breaks things — because staging and live are different environments wearing the same design. The usual culprits, all worth a specific re-check on the real domain: email delivery (staging often sends through a test mailer or is whitelisted; live form notifications hit real spam filters, which is why check 8 repeats on the live domain); payment keys (test/sandbox keys left in place mean real cards are declined — or, worse, live mode was never enabled and orders are imaginary); SSL and domain variants (the certificate may cover the bare domain but not www, or the reverse); scheduled tasks (backup and security jobs configured on staging do not migrate themselves); and caching (a page cache or CDN switched on at launch can serve yesterday's pages to today's visitors, including you while you test). The launch-day section below exists precisely because this gap exists: re-run the money tests — form, payment, phone — on the live domain, every time.
Launch Day and the Week After
Go live early in a working day, never Friday evening: the people who can fix things should be awake and available for the first hours. After switching, repeat the form test and the phone browse on the live domain (staging passes tests the live site can still fail), watch analytics real-time for your first real visitors, and check Search Console over the following days for crawl errors. Keep the old site's backup and redirect map untouched for at least a few months.
Then hand over to routine: the checks that keep a launched site healthy — updates, backups, uptime, content reviews — are a maintenance rhythm, not a launch event; our guide to website maintenance costs prices that rhythm for US readers, and the principles translate anywhere. More launch and growth guides live on the Asad Webs blog.
Extra Checks if You Sell Online
Stores add a second money path, and it needs its own pass (checks 12 and 29 cover the basics):
- One complete real order, start to finish: buy the cheapest product with a real card — product page, cart, checkout, payment, confirmation email, order appearing in the admin, and a packing notification if you send one. Then refund it and confirm the refund email and the money's return path.
- Tax and shipping rules per zone: place test orders to each region you serve and verify the totals — wrong shipping zones are the classic week-one store embarrassment, charging too little to far addresses or blocking near ones entirely.
- Transactional emails: order confirmation, dispatch and refund emails all arrive, read correctly and come from your domain — these are the messages customers keep.
- Stock behaviour: buy the last unit of something and confirm the product shows out of stock rather than overselling; then restore the stock level.
- Abandoned-cart and account emails fire if you enabled them — or are off if you did not mean to enable them. Silence and surprises are both bugs here.
The First-Week Monitoring Routine
Launch is a week, not a moment. A light routine catches the stragglers:
- Day 1: form and payment tests on the live domain (again), a full phone browse, and a look at analytics real-time to confirm real visitors are being recorded — including which pages they land on.
- Days 2–3: Search Console's Pages report — are the new URLs being indexed, and is anything important flagged? Request indexing for the homepage and your top service page if they lag.
- Day 7: check the 404 log or Search Console for URLs visitors or search engines requested that do not exist — these are redirect-map misses, printed links and directory entries pointing at the old site. Fix each with a proper redirect to its equivalent.
- End of week one: confirm the first real backup of the LIVE site exists (not the staging one), domain and SSL renewal dates are in a calendar someone owns, and the launch notes — what was changed, what was deferred — are written down while the team still remembers them.
Want this as a printable worksheet for your desk? The WordPress Business Website Launch Checklist in the Asad Webs shop is the tick-box companion to this article.
Launching soon and want a second pair of eyes on this list? Book a free consultation — send us your site before launch day and we will flag the issues that would hurt you most in week one, with no obligation.
Frequently Asked Questions
What is the most important check before launching a website?
Submit every form and confirm the messages arrive in a monitored inbox. A beautiful site whose enquiries vanish is worse than no site, because the business believes it is reachable when it is not.
How long does a launch check take?
About an hour for a typical small-business site if you work the list in order, plus time to fix what you find. That hour is cheaper than any single item on the 'cost if missed' list.
Do I need redirects if my site is brand new?
Only if something existed before — an old site, a previous domain, or pages that others have linked to. A truly first website on a fresh domain has nothing to redirect, but still needs the sitemap, Search Console and indexing checks.
Should I launch on a Friday to have the weekend to fix things?
No — launch early on a normal working day. Your host, developer and payment provider are all reachable then, and most launch issues surface within the first hours of real traffic.
What's the difference between this checklist and the shop version?
This article is the complete method, free. The shop version is the same checks formatted as a printable tick-box worksheet with notes space — for people who want the document on the desk during launch day.
We already launched and skipped some checks. Is it too late?
No — run the list now. Most items (forms, indexing, redirects, backups, analytics) can be checked and fixed at any point after launch; they only get more expensive the longer they sit, because every week of a broken form or a blocked index is enquiries and rankings that did not happen. Redirects in particular are worth building late rather than never.
Who should own this checklist — me or my developer?
The business owns it; the developer performs the technical items. Checks about inboxes, phone numbers, prices and legal pages can only be verified by someone who knows the business, while indexing, redirects and SSL are developer territory. Split the list explicitly before launch day so nothing is 'the other person's job'.
Be the first to share a useful question or thought.