Launch day problems are rarely exotic. They are a staging site that shipped with search engines blocked, a contact form that submits successfully and emails nobody, and a redirect map that covered the pages someone remembered.
Here are thirteen checks, in the order we run them. The first two account for most of the damage we have been called in to repair.
1. Map every old URL to a new one
If this is a relaunch rather than a first launch, this is the check that protects everything you have already earned. Crawl the live site, export every URL, and map each one to exactly one address on the new site. Documents count. PDFs rank and attract external links on their own.
Use permanent redirects, one hop each, never a chain. Then request each old URL and confirm it lands on a live page rather than a 404 or another redirect. A spreadsheet that says the map is complete is not the same as a test that proves it.
2. Remove the staging noindex, and read robots.txt
The single most expensive launch mistake in WordPress is shipping with “Discourage search engines from indexing this site” still ticked in Settings, Reading. Sites have sat invisible for months this way, and the symptom looks exactly like a site that simply is not ranking yet.
Check the setting, then fetch /robots.txt and read it. Confirm it does not disallow anything you need indexed, and that it points to your sitemap. Then spot check a few templates for a stray noindex meta tag left behind by a plugin or a theme option.
3. Proofread everything, out loud, in every language you publish
Read it aloud, because your eye skips what your ear catches. Get someone who did not write it to read it too. Check the places nobody proofreads: form labels, error messages, confirmation screens, button text, the 404 page, email templates and page titles.
If you publish bilingually, check that every French page is actually French. Partially translated templates with English validation messages are extremely common and immediately visible to the people you are trying to serve.
4. Test every form end to end, including the email
Submitting a form and seeing a thank-you message proves the front end works. It proves nothing about delivery. Submit each form for real and confirm the notification arrives, at the right address, with the field values intact and a reply-to you can actually reply to.
Check the spam folder, because a new site sending mail from a new server frequently lands there. If you have SPF, DKIM and DMARC records, verify them now rather than discovering the problem through the enquiries you never received. Test the failure paths too: submit with required fields empty and confirm the errors are clear and announced to assistive technology.
5. Run an accessibility pass
Automated tooling catches roughly a third of issues, so run it, then do the manual part. Traverse each template with the keyboard alone and confirm you can reach and operate everything, that focus is always visible, and that nothing traps you. Check colour contrast against the 4.5:1 requirement for body text. Confirm images have meaningful alt text and decorative ones have empty alt attributes.
If you have an obligation to a specific standard, whether WCAG 2.2 Level AA, the AODA in Ontario or SGQRI 008 3.0 in Quebec, record the result per criterion rather than as a single pass or fail.
6. One H1, and a unique title and description per page
Every page needs exactly one H1, and headings should descend in order without skipping levels, because that structure is how screen reader users navigate as well as how search engines read the page.
Every page also needs its own title tag and meta description. Duplicates across a site are the most common on-page problem we find, and they usually come from a template default nobody overrode. Meta keywords are dead and have been for years, so ignore any plugin still offering the field.
7. Check Core Web Vitals on the templates that matter
Test the homepage, a content page, a listing page and any form or checkout, on a mid-range phone rather than your laptop. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1.
Layout shift is the one most often missed before launch, and it usually comes from images without width and height attributes, web fonts swapping late, or an advertisement or banner injected above content after render.
8. Optimize the images, and give them real alt text
Serve modern formats, size images to the dimensions they actually display at, and lazy load anything below the fold while explicitly not lazy loading your largest above-the-fold image. Check on a slow connection, not your office network.
Alt text describes the image’s purpose in context, not its contents. If an image is purely decorative, an empty alt attribute is correct and better than a filename.
9. Check it on real browsers and real devices
Current versions of Chrome, Safari, Firefox and Edge, plus Safari on an actual iPhone and Chrome on an actual Android device. It does not have to be pixel identical. Everything has to work.
Test in dark mode if your visitors’ devices may be in it, and test at 200 percent browser zoom, which is both an accessibility requirement and a fast way to find layouts that break.
10. Install and verify analytics and Search Console
Put analytics in place before launch so you have a baseline from day one. Confirm it fires on every template rather than only the homepage, and that any consent banner does not silently block it.
Verify the property in Google Search Console at the same time. If you have changed domain, add both properties and use the change of address tool. Define what a conversion is and confirm you can see one before you need to report on it.
11. Submit the XML sitemap
Fetch the sitemap and read it. Confirm it lists the pages you want indexed and does not list drafts, staging URLs, attachment pages or paginated duplicates. Then submit it in Search Console and check back a few days later for coverage errors, which is where a misconfiguration surfaces first.
12. Build a 404 page that recovers the visit
Someone will arrive at a URL that no longer exists no matter how good your redirect map is. A 404 page that offers search, your main sections and a route to contact turns a dead end into a recovered visit. Confirm it returns an actual 404 status code rather than a 200, because a soft 404 confuses search engines and hides the problem from your reports.
13. Back it up, then prove the backup restores
An untested backup is a belief, not a safeguard. Take a full backup of files and database, stored somewhere other than the server it came from, then actually restore it somewhere and confirm the site comes up.
While you are securing things: confirm HTTPS is enforced site-wide with no mixed content warnings, remove the default admin account and any test users, turn on two-factor authentication for administrators, and write down who holds the domain, the DNS and the hosting credentials.
The small things, quickly
- Favicon in place, at the sizes modern browsers and mobile bookmarks expect.
- Logo links to the homepage.
- Open Graph tags, checked by pasting a URL into the platform where it will be shared.
- A single canonical hostname, with www and non-www resolving to one of them.
- Print styles, if anyone prints your pages. Public sector visitors do.
- Privacy policy, cookie notice and any legal pages actually linked, not just published.
The day after
Launching is not the end of the checklist. In the first week, watch Search Console for crawl errors and coverage changes, watch your server logs for 404s coming from real traffic, confirm indexing is progressing, and check that forms are still delivering. Expect a temporary dip in search visibility after a relaunch. What should concern you is a dip that does not recover, which almost always traces back to check number one or check number two.
Our earlier quality assurance checklist is still available as a PDF. It predates the list above and does not cover the first two checks, but it is a useful second pass over the details.
If you would rather someone else ran this list, our custom WordPress development page explains how we build and launch, and what we hand over.