Website launch checklist — the pass before it leaves your hands

Not the logo, not the tagline, not three of them because the theme styles H1 the way the design wanted. The H1 is the page in one line, and it should read sensibly with no other context.

H2 under H1, H3 under H2. Skipping from H2 to H4 because H3 looked too big is the most common accessibility failure on a finished site, and it is a styling problem wearing a structure problem.

Screen reader users navigate by heading. A page whose headings are chosen for size rather than rank is genuinely harder to use, not just technically wrong.

Unique, under about 60 and 155 characters, and written for the person reading the search result rather than for a keyword. Duplicated titles across a site are a signal you did not finish.

Search the built site for "lorem", "TODO", "coming soon" and the client name spelled wrong. Check the 404 page, the form success message and the email templates — the three places nobody looks.

Describe what the image shows and why it is there, not what it is. "Chart: support tickets falling by half after launch" beats "chart.png" and beats "image of a chart".

alt="" tells a screen reader to skip it. A missing alt attribute makes it read the filename instead, which is how visitors end up hearing "D S C underscore 4 0 9 2 dot j p g".

A 4000px photograph in a 400px slot costs the visitor the whole download for pixels they never see. This is the single most common reason a finished site feels slow on a phone.

Images without dimensions push the page around as they load. Set them, or reserve the space with an aspect ratio, and the layout stops shifting under the reader.

Muted and user-started. If it must autoplay, it is muted, short, and it is not carrying anything the visitor needs to hear.

Run the crawl again after the last content change, not before it. External links rot quietly, so check them on launch day rather than trusting a crawl from a fortnight ago.

On a rebuild, every URL that was indexed needs a 301 to its nearest equivalent. Pull the old list from the sitemap, Search Console or the server logs — guessing from the new menu misses everything that was linked but unlisted.

This is the one that costs real money. A rebuild that drops its redirects loses the rankings the old site earned, and the loss shows up weeks later when nobody is looking for it.

If they open in a new tab, they do it consistently, and anything user-generated or untrusted carries rel="noopener". Do not open internal links in new tabs — it takes the back button away.

Jump links, table-of-contents links and skip links all land on the right element with the heading visible rather than hidden behind a sticky header.

Dragging the window misses touch behaviour, the on-screen keyboard, real font rendering and the address bar eating viewport height. Open it on a phone before you call it done.

One over-wide element is enough to make the whole page slide. The usual suspects are tables, code blocks, long unbroken URLs and a negative margin someone used to break out of a container.

Around 44px, with space between them. Adjacent links in a footer or a tag row are the ones that fail, and they fail hardest for the people with the least steady hands.

Open the mobile menu and close it again. Scroll a wide table. Fill in a form with the keyboard up. These three break far more often than the layout does.

Safari on iOS is the second browser most sites meet and the first one they break in. Check the dates, the form controls and anything using a recent CSS feature.

Click all of them. Placeholder hrefs, a personal account left in from the template, and a profile that was renamed six months ago are all normal findings.

Paste the URL into the tools each platform provides and look at what comes back. An og:image that 404s or sits behind a login shows as a blank card, which is worse than no card.

1200x630 or thereabouts. Any text on it has to survive being shown at a third of that size in a feed.

og:title and og:description can differ from the page title — a search result and a shared card are read in different frames of mind.

The single most expensive launch mistake: a staging noindex or a Disallow rule shipped to production. Check the live robots.txt and check the page source for a robots meta tag before anything else.

A site can look perfect and be invisible for weeks. Check this on the live domain after go-live, not on staging beforehand.

The sitemap lists what should be indexed, robots.txt does not block it, and the sitemap is referenced from robots.txt. Submit it once the domain is live.

One canonical per page, absolute, and self-referencing unless there is a deliberate reason otherwise. A canonical left pointing at staging is a quiet way to deindex a whole site.

Organisation and LocalBusiness where relevant, Article on posts, Breadcrumb on deep pages. Run it through a validator — invalid markup earns nothing and can be worse than none.

www or not, http redirects to https, and everything resolves to the same choice in one hop. Chains of redirects waste crawl budget and slow the first visit.

Submit each one for real and confirm it lands. Check the spam folder, and check that the from-address is one the domain is allowed to send as, or the mail quietly disappears.

A contact form that silently fails looks identical to one that works. It is the most expensive bug on a business site because nobody reports it — the enquiries just stop.

Errors say what is wrong and how to fix it, they appear next to the field, and they are announced rather than only coloured red.

A honeypot or a rate limit before a CAPTCHA. If you must use a CAPTCHA, check it is passable with a keyboard and a screen reader.

"Thanks" is not enough. Say who will reply and roughly when, and give an alternative route in case they need it sooner.

Run it through Lighthouse or PageSpeed and read past the score to the actual complaints. Optimising by instinct usually means installing another plugin, which is how sites get slow in the first place.

Find what the largest contentful paint actually is — usually a hero image — and make sure it is not lazy-loaded, not waiting on JavaScript, and not larger than it needs to be.

Fonts, third-party scripts and analytics belong after the first paint. A chat widget that blocks rendering costs more than it earns.

Text compressed, static assets given long cache headers with a hash in the filename, and a CDN in front if the audience is not local.

4.5:1 for body text, 3:1 for large text. Check the hard cases: text over photographs, text on brand colours, placeholder text and anything greyed to look subtle.

Tab through it. Every interactive thing is reachable, the order follows the page, menus and modals can be opened and closed, and nothing traps focus.

If the design removed the outline, something replaced it. A keyboard user who cannot see where they are cannot use the site at all.

A placeholder is not a label — it disappears the moment someone types. Every input has a label, and icon-only buttons have an accessible name.

header, nav, main, footer, and html lang set correctly. These are what let assistive technology skip to the content instead of reading the menu every time.

If analytics or embeds set cookies, consent comes first and declining genuinely works. A banner that sets the cookies anyway is worse than no banner.

For a UK company: registered name, number and address. Plus a VAT number if registered, and the trading address if it differs.

Not twice through both a plugin and the theme, which doubles every number. Load the live site and confirm a real-time hit before handing over.

A hardcoded year is a small thing that makes a site look abandoned every January.

Including www if it resolves. Check the expiry date and confirm auto-renewal is on rather than a note in somebody’s diary.

A live staging copy competes with the real site and leaks unfinished work. Password it or take it down the day you launch.

A backup nobody has ever restored is a hypothesis. Restore one somewhere harmless and confirm it produces a working site.

Domain, hosting, analytics and any third-party service registered to their email, not yours. Hand over credentials properly and remove any account that should not outlive the project.

On the live domain, after the noindex check. This is where you find out within days if something is wrong, rather than within months.