01
1. Search and sharing: the mistakes that hide a site
Check these on the live address right after launch, because staging settings often travel with the site.
- No noindex meta tag or X-Robots-Tag header, and robots.txt doesn’t block the pages
- The canonical tag points at the live address, not staging or localhost
- Every page has a unique title (about 50–60 characters) and a meta description
- og:image is set with a full https:// address, so link previews show a picture
- A favicon, and an XML sitemap submitted in Google Search Console
Watch out: A noindex left over from staging is the most common launch mistake. It hides the whole site from Google until someone notices.
02
2. Every screen size, not just yours
Test at the sizes visitors use: phones around 360–430px, tablets at 768–1180px, laptops at 1280–1536px and Full HD. Look between breakpoints too: many layouts break at a width nobody designed for.
- No sideways scrolling on any phone width
- No cut-off or overlapping text, buttons and images
- The menu opens, closes and fits the screen
- Buttons and links are big enough to tap
- Images fit and aren’t stretched or squashed
03
3. Browsers
Chrome, Safari and Firefox render the same CSS slightly differently. Safari matters most: it is the only browser engine on iPhones. Test in Safari even if your team works on Windows.
04
4. Links, forms and errors
- No broken links, including the ones in closed menus and the footer
- Every form sends, shows a clear success message, and reaches the right inbox
- Required fields and wrong emails show an error next to the field
- No errors in the browser console and no images that fail to load
- Links and files no longer point at the staging site
05
5. Accessibility basics
- Text contrast of at least 4.5:1 (3:1 for large text)
- Every field has a visible label; every image that says something has alt text
- The whole page works with the keyboard, with a visible focus outline
- One H1 per page and headings in order
06
6. Speed and stability
Pictures should be no larger than they are shown and saved as WebP or AVIF; images below the first screen should load lazily. Give images a width and height so the page doesn’t jump while it loads.
07
7. Moving to the live address
- Domain points at the new host (DNS), with www and the bare domain both working and redirecting to one of them
- HTTPS works on every page, the certificate is valid, and http:// redirects to https://
- Email (MX records) still works if the domain moved hosts
- Old page addresses redirect to their new ones with 301 (permanent) redirects, so links and rankings carry over
- A helpful 404 page for anything that doesn’t exist
08
8. Analytics, tracking and consent
- Analytics installed on every page and recording visits from the live address, not staging
- Key actions (sign-ups, form sends, purchases) tracked as events or conversions
- Search Console set up for the domain, with the sitemap submitted
- A cookie banner where your visitors’ laws need one, and the privacy policy linked from the footer
09
9. Security, backups and performance
- CMS, themes and plugins updated; test accounts and default passwords removed
- Automatic backups running, and one restore tested
- Page caching and a CDN switched on if the host offers them
- Forms protected against spam
- Uptime monitoring so you hear about downtime before your visitors do
10
10. Content and legal
- No placeholder text, test products or “lorem ipsum” left anywhere, including meta descriptions and image alt text
- Contact details, prices and opening hours correct
- Privacy policy, terms and any required notices published
- Spelling checked on the main pages
11
After launch: the first week
- 1Re-run the search checks on the live address the same day
- 2Watch Search Console for crawl errors and pages not indexed
- 3Check analytics for pages with no visits or very high exits
- 4Send a test from every form again on the live site
- 5Monitor the main pages so you hear when something changes or breaks
12
Do it in minutes instead of a day
Clicking through every page on every device takes hours and still misses things. UICheck runs most of this checklist on every page at every screen size in one check, and lists each problem with a screenshot and the fix, so the manual part is only what needs a person: content, flows and sign-off.
Checklist
Questions
How do you test a website before launch?
Check search settings (noindex, canonical, titles), every screen size, Safari and Firefox, links and forms, accessibility and speed, on the staging site and again on the live address. An automatic check covers most of it; a person checks content and key flows.
What should a website QA checklist include?
Search and sharing tags, responsive layout at phone, tablet and desktop sizes, browser differences, broken links, form sending and validation, accessibility (contrast, labels, keyboard), speed, and the site’s content.
When should I run the pre-launch checks?
On staging before launch, then again on the live address right after, because settings such as noindex and staging links often change in the move.
What is the most common mistake when launching a website?
A noindex tag or robots.txt rule left over from staging, which hides the new site from Google. Check it on the live address right after launch.
What should I do after launching a website?
Re-check search settings on the live address, submit the sitemap, send a test from every form, watch Search Console and analytics for a week, and keep monitoring the main pages.