Most launch day problems are ordinary ones. A staging site goes live with search engines still blocked, a contact form thanks the visitor and emails nobody, and the redirect map covers only the pages someone remembered. Run these checks before you launch a website and you catch them while they still take an afternoon to fix.
The thirteen checks below are in the order we run them. Give the first two the most attention, because a mistake there can cost months of search traffic before anyone notices.
1. Map every old URL to a new one
On a relaunch, this check protects the search traffic and links the old site has already earned. Crawl the live site, export every URL and give each one exactly one address on the new site. Include the documents. PDFs rank in search and collect links of their own, and they are easy to leave off the map. If your site holds thousands of them, our guide to migrating documents without losing search visibility covers the method.
Use permanent redirects that reach the new page in a single hop. Then request each old URL and confirm it lands on a live page. A 404 or a second redirect means the map has a hole, and a spreadsheet marked complete can’t tell you that. Our website redesign and modernization page explains how we handle the mapping on a relaunch.
2. Remove the staging noindex, and read robots.txt
One of the most expensive WordPress launch mistakes is leaving “Discourage search engines from indexing this site” ticked under Settings, Reading. The box gets checked on staging and forgotten at launch. The site can then stay out of search results for weeks. It looks like a new site that hasn’t started ranking yet, so nobody goes looking for a cause.
Check the setting, then open /robots.txt and read it. It should block nothing you want indexed, and it should point to your sitemap. Finally, look at the source of a few templates for a stray noindex meta tag left by a plugin or a theme option.
3. Proofread everything, out loud, in every language you publish
Read every page aloud, because the ear catches what the eye skips. Have someone who didn’t write the text read it too. Then go through the places nobody proofreads: form labels, error messages, confirmation screens, button text, the 404 page, email templates and page titles.
If you publish in two languages, make sure every French page is French all the way through. A French form that answers with English validation messages is a common sight. Your French-speaking visitors will be the first to see it.
4. Test every form end to end, including the email
A thank-you message on screen only tells you the form was submitted. Whether anyone received it is a separate question. Submit each form for real and check that the notification arrives at the right address, with every field value intact and a reply-to address you can answer.
Look in the spam folder as well, since mail from a new site on a new server often ends up there. If your domain has SPF, DKIM and DMARC records, verify them now, before missing enquiries tell you something is wrong. Then test the failure path. Submit with the required fields empty and confirm the error messages are clear and announced to screen readers.
5. Run an accessibility pass
Automated tools find only part of the accessibility problems on a page, so run them first and then do the manual work. Go through each template with the keyboard alone. You should be able to reach and use every control, see where the focus is at all times and never get stuck. Check that body text meets the 4.5:1 contrast ratio. Images that carry meaning need alt text, and decorative ones need an empty alt attribute.
If you must meet a specific accessibility standard, such as WCAG 2.2 Level AA, WCAG 2.0 Level AA under the AODA in Ontario or SGQRI 008 3.0 in Quebec, record the result for each criterion. A single pass or fail is hard to act on, and harder to defend when someone asks for the details.
6. One H1, and a unique title and description per page
Each page needs one H1, and the headings below it should step down in order without skipping a level. Screen reader users move through a page by its headings, and search engines read the same structure.
Each page also needs its own title tag and meta description. Duplicates are a frequent on-page problem, and they usually come from a template default that nobody replaced. If a plugin still offers a meta keywords field, leave it empty. Google stopped using it years ago.
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. Your own laptop will flatter the results. The targets are a Largest Contentful Paint under 2.5 seconds, an Interaction to Next Paint under 200 milliseconds and a Cumulative Layout Shift under 0.1.
Layout shift is the one teams tend to miss before launch. It usually comes from images that have no width and height attributes. Web fonts that swap in late can cause it too, as can a banner pushed in above the content after the page has loaded.
8. Optimize the images, and give them real alt text
Serve modern formats such as WebP or AVIF, and size each image for the space it actually fills on screen. Lazy load the images below the fold. Skip it for the large image at the top of the page, since that image often sets your Largest Contentful Paint. Test on a slow mobile connection as well as the office network.
Good alt text says what the image does on the page. A product photo next to a price needs the product’s name, while a photo used as a link needs the destination. When an image is purely decorative, an empty alt attribute is the right answer, and a screen reader will skip it instead of reading out a filename.
9. Check it on real browsers and real devices
Test the current versions of Chrome, Safari, Firefox and Edge, then Safari on a real iPhone and Chrome on a real Android phone. Small visual differences between browsers are fine as long as every menu, form and button works.
Try dark mode if your visitors’ devices may use it. Then zoom the browser to 200 percent. WCAG requires text to stay usable at that size, and it is a quick way to find layouts that break.
10. Install and verify analytics and Search Console
Install analytics before launch so you have numbers from the first day. Check that tracking fires on every template, and that the consent banner isn’t quietly blocking it.
Verify the site in Google Search Console at the same time. After a domain change, add both properties and use the Change of Address tool. Decide what counts as a conversion, and make sure you can see one in your reports before anyone asks for the numbers.
11. Submit the XML sitemap
Open the sitemap and read it. It should list the pages you want indexed and leave out drafts, staging URLs, attachment pages and paginated duplicates. Submit it in Search Console, then come back a few days later and open the page indexing report. A configuration mistake tends to show up there first.
12. Build a 404 page that helps people find their way
However careful the redirect map, someone will land on a URL that no longer exists. Give the 404 page a search field, links to your main sections and a way to contact you, so those visitors have somewhere to go. Then check the status code. The page must return a real 404. A “page not found” message served with a 200 status is a soft 404, which confuses search engines and keeps the broken links out of your reports.
13. Back it up, then prove the backup restores
Until you have restored a backup, you are only hoping it works. Take a full copy of the files and the database and store it away from the server it came from. Then restore it somewhere and confirm the site comes up.
Tighten security while you are at it. Confirm HTTPS is enforced on every page with no mixed content warnings. Rename any administrator account called admin, delete the test users and turn on two-factor authentication for administrators. Then write down who holds the access to the domain, the DNS and the hosting.
The small things, quickly
- A favicon at the sizes browsers and phone home screens use.
- The logo links to the homepage.
- Open Graph tags, checked by pasting a URL into each platform where it will be shared.
- One canonical hostname, with the www and non-www versions both resolving to it.
- Print styles, if people print your pages. Look at a long page and a table in print preview.
- The privacy policy, cookie notice and other legal pages, linked where visitors expect to find them.
The day after
The checklist runs for a week past launch. Watch Search Console for crawl errors and indexing changes, look in the server logs for 404s from real visitors, and keep testing the forms. A short dip in search visibility after a relaunch is normal. If it hasn’t recovered after a few weeks, go back to checks one and two, where the cause usually lies.
If you would rather hand this list to someone else, our custom WordPress development page explains how we build and launch a site, and what we hand over at the end.