The Ultimate Website QA Checklist

Benjamin Franklin may have once said, “…in this world nothing can be said to be certain, except death and taxes,” but had he worked in website development, he may well have added a third certainty: the need for Quality Assurance.

Having spent years in the trenches of website design, watching startups and established businesses launch, I have seen how much the success of a site depends on its quality on day one.

That is what QA is for. A set of checks that make sure a website does not just meet expectations for functionality, usability and design, but beats them.

If you would rather work with the live app version, where you can print the whole thing out, open the interactive checklist here.

Fourteen steps, 195 checks, plus a bonus round that takes the total to 207. Let’s get into it.

Step 1: Planning and preparation

Set measurable standards, equip the team, and make ownership explicit.

Starting a web project without a plan is like sailing without a compass. The point is not just having one, but making sure every person on the team knows their part in it. This first step is about setting clear targets, picking your tools, and deciding who owns what.

Set your targets. Quality shows up in a few different forms: how fast the site is, how consistent it looks, how secure it is, and whether things actually work. Write down what good looks like for each one, with numbers you can check. Vague targets do not survive contact with reality, because the platforms measuring your site use precise numbers, and so should you.

Pick your tools. Atarim changed how feedback moves between developers, designers, testers and clients by letting people annotate the live site directly, and it now handles a growing share of the QA work itself. You can run an AI design review on a page or a graphic, pull Lighthouse reports on demand, and scan connected WordPress sites for vulnerabilities across every plugin and theme. It does not replace the human judgement in this checklist, but it does catch the obvious problems before anyone spends an afternoon hunting for them.

For task management, Jira, Asana, ClickUp and Trello all do the job. Whichever you use, the point is that QA feedback should land in the tool your developers already use, not a second place they have to check.

Decide who owns what. QA engineers write and run the tests and verify fixes. Developers fix what QA finds. Project managers keep the resources flowing. Designers protect the visual standard. Content and SEO leads own metadata, structured data, and how the site presents itself to AI systems.

One role almost nobody assigns: whoever controls the CDN owns bot policy. The decision about which AI systems are allowed to read your website is a business decision with a technical implementation, and it lives in a dashboard your marketing team probably cannot see. Give it a name.

Checklist (9)

• Write down what good looks like for performance, design, security, and functionality, with numbers you can check
• Main content loads in under 2.5 seconds for 75% of real visits, measured from real visitors rather than a test run
• Commit to WCAG 2.2 Level AA across every template, verified manually and not just by a scanner
• Agree on zero critical or high-severity vulnerabilities at launch, with a patching cadence after it
• Pick the three most valuable things an AI agent should be able to do on the site without help
• Set up the QA toolkit: annotation on the live site, AI design review, Lighthouse, vulnerability scanning
• Send QA feedback into the tool your developers already use, not a second place they have to check
• Assign roles explicitly: QA, developers, project management, design, and content and SEO
• Name the person who owns bot policy at the CDN, because nobody owns it by default

Step 2: Design and UI testing

Visual consistency and real device behaviour, on every template.

What your site looks like and how it responds is most of what people judge it on. This step is about visual consistency and real behaviour on real devices.

Checklist (14)

Visual consistency

• Colour palette consistent across all pages and all interactive states
• Fonts uniform in style, size, and weight throughout the site
• Elements aligned correctly against the design mock-ups
• Images high quality, correctly placed, and consistent with the design specification
• Icons uniform in style and size across the site
• Empty, loading, and error states designed rather than left to browser defaults

Responsiveness and device compatibility

• Layouts adjust properly across desktop, tablet, and mobile
• Touch interactions work smoothly on touch devices
• Navigation stays accessible and functional on small screens
• Images and video scale without distorting
• Modals and pop-ups display and function correctly on every device
• Every template checked in both light and dark mode, or dark mode deliberately switched off
• Animations respect the user’s reduced motion preference
• Content clears notches, home indicators, and rounded display corners

Step 3: Accessibility testing

The same structure that serves a screen reader is the one an AI agent reads.

Making your site usable for people with disabilities is a legal obligation in many countries, and it is traditionally the item everyone agrees is important and then skips under deadline pressure. Legislators are ending that era on a fixed schedule.

There is a second reason to care. The same markup that serves a screen reader is what makes your site readable to an AI agent. Google’s guidance on building for AI agents says agents perceive your site through screenshots, raw HTML, or the accessibility tree, and the quality of that representation decides whether they succeed. OpenAI’s developer guidance points the same way, recommending WAI-ARIA practices.

The structure you build here is what an agent navigates in Step 9, which makes this the highest-leverage work on the list.

Checklist (21)

• Colour contrast: 4.5:1 on text, 3:1 on large text and interface components
• Meaningful alt text on informative images, empty alt attributes on decorative ones
• Every interactive element reachable and operable without a mouse
• A clear, high-contrast focus indicator that is never suppressed by CSS
• Tab order follows visual order, and modals both trap and correctly restore focus
• Genuine end-to-end flows run with NVDA, JAWS, or VoiceOver
• One H1 per page, no skipped levels, and headings that describe their content
• Every input has a programmatic label, and errors are specific and announced
• Interactive targets meet the 24 by 24 CSS pixel minimum or have adequate spacing
• No cognitive function tests in authentication, and password fields accept pasted input
• Support and contact options appear in the same place across pages
• Anything drag-based offers a single-pointer alternative
• Links are identifiable and descriptive beyond generic terms like “click here”
• Captions on video, transcripts on audio, and no autoplay with sound
• The page declares its language, so screen readers pronounce it correctly
• Zoom to 400% on desktop and nothing scrolls sideways or gets cut off
• If someone increases line and letter spacing in their browser, nothing overlaps or disappears
• Focus is never obscured by a sticky header, cookie bar, or chat widget
• Nobody is asked to re-enter something they already gave you earlier in the same process
• Accessibility statement published, dated, and with a real route to a human
• No overlay widget standing in for actual remediation work

Google’s guidance on building for AI agents notes that agents perceive a site through screenshots, raw HTML, or the accessibility tree, and the quality of that representation decides whether they succeed. This is the highest-leverage work in the checklist.

Step 4: Functional testing

Everything a visitor can click, submit, or break.

This is where you check that the practical parts of the site actually work, under normal conditions and awkward ones. Navigation links, forms, and the content that loads after the page does all get tested here. Share previews and icons live here too, because a blank card in Slack on launch day is the first thing anyone notices.

Checklist (22)

Navigation and links

• Internal links reach the correct pages without errors or unnecessary redirect chains
• External links open correctly and lead to the right destinations
• Navigation menus order items correctly and every link works
• Call-to-action buttons trigger the appropriate action
• A custom 404 page exists, is genuinely helpful, and returns a real 404 status code
• Redirects from any previous URL structure are in place and tested

Forms and input fields

• Submissions are captured and sent to the correct server-side handler
• Input fields enforce proper validation rules and reject invalid entries
• Error messages display correctly, are specific, and are announced to assistive technology
• Forms are secure against common threats and sensitive data is handled appropriately
• Spam protection stops bots without blocking real people, screen readers, or AI agents
• Confirmation emails and internal notifications fire from production and reach real inboxes

Sharing and icons

• Open Graph title, description, and image set on every template
• Twitter card tags present, with the image at the right ratio
• Share previews checked in the platform debuggers rather than assumed
• Favicon, apple touch icon, and manifest icons all present at the right sizes
• Theme colour and site name set, so pinned and saved versions look right

Content and rendering

• The important content is in the page itself, and still readable with JavaScript turned off
• Dynamic content loads without errors, flicker, or layout jumps
• Nothing important is hidden behind a tab, dropdown, or pop-up
• Search returns accurate and relevant results
• Anything that loads in the background still behaves on a slow or dropped connection

Step 5: Performance optimisation

Field data, not lab scores, and behaviour under load you have actually measured.

Speed matters as much as function. People have little patience for a slow page, and search engines have no obligation to rank a site that frustrates the visitors they send to it.

The important shift is where you measure. Scores from a single test run tell you very little. What counts is data from real visitors, which is what the first four items below are about.

Checklist (16)

Core Web Vitals and loading speed

• Largest piece of content on screen loads in under 2.5 seconds for 75% of real visits
• Clicks and taps respond within 200 milliseconds for 75% of real visits
• Nothing jumps around while the page loads, scoring under 0.1 for 75% of real visits
• Scores checked against real visitor data, not just a one-off Lighthouse run
• Images compressed without quality loss, served in modern formats, with explicit dimensions
• CSS and JavaScript minified, and anything not needed for first render deferred
• Fonts trimmed to what you use, the main one loaded early, and a backup font set
• Browser caching rules configured and verified as actually applied
• Every third-party tag reviewed, and anything nobody uses removed

Stress testing

• High traffic simulated and site behaviour monitored
• The traffic level at which the site degrades identified and written down
• Load balancing confirmed to be distributing traffic effectively
• AI and search crawler traffic accounted for in capacity planning

Resource usage

• CPU and memory usage monitored and recorded under normal and peak conditions
• Database queries optimised and slow queries logged
• Server response time measured and hitting the target you set

Step 6: Security testing

Find the vulnerabilities before somebody else finds them for you.

Security is not negotiable. As threats get more sophisticated, protecting your site matters both for the data it holds and for the trust of the people using it.

This step is about finding the holes before someone else does: scans, encryption, authentication, WordPress-specific hardening, and one category most checklists have not caught up with yet.

Checklist (17)

Vulnerability scans

• Scheduled and ad-hoc scans running with reputable tools
• Penetration testing conducted against anything handling sensitive data
• All software, plugins, and themes up to date
• Third-party code scanned automatically every time the site is built

Data encryption and protection

• HTTPS in use across all pages, not just login and payment
• HSTS enabled and a genuinely restrictive Content Security Policy set
• Strong encryption verified for data in transit and at rest
• Stored data audited, minimised, and given defined retention periods

Authentication and session management

• Login pages tested for vulnerabilities, with rate limiting applied
• Secure cookie handling and appropriate session expiration confirmed
• MFA enforced on all administrative access, with passkeys where supported

WordPress hardening

• Unused plugins and themes deleted rather than just deactivated
• File permissions correct and directory listing disabled
• Admin usernames cannot be guessed from the site, and repeated login attempts are throttled
• XML-RPC disabled or restricted if nothing depends on it

AI features and recovery

• Any AI assistant on the site resists prompt injection and cannot reach data it should not
• Backups running, and a restore actually tested rather than assumed

Step 7: AI crawlability and bot access

Three kinds of crawler, three separate decisions, and one very common accident.

Your website is being read by machines that decide what to tell people about your business. Whether they can read it, whether they are allowed to, and whether you have locked them out by accident are three separate questions, and most teams have not deliberately answered any of them.

The three jobs AI crawlers do. Almost every bad decision here comes from treating them as one category. They are not, and the block that protects your content from one type quietly deletes you from the other two.

Training crawlers collect text to train models. They send nothing back: no traffic, no citation, no click. This group includes GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, Bytespider and Meta’s crawler.

Search and index crawlers build the indexes that AI answers are actually assembled from. OAI-SearchBot feeds ChatGPT’s search, Claude-SearchBot supports Claude’s web answers, and PerplexityBot feeds Perplexity. Block these and your pages cannot be retrieved, and if they cannot be retrieved they cannot be cited. This is the group people block by accident and then wonder where they went.

User-triggered fetchers act for a live person in real time. ChatGPT-User, Claude-User and Perplexity-User fire when somebody inside one of those products opens or asks about your page. These are the closest thing to a human visit, and several providers note they may not strictly follow robots.txt precisely because a person asked.

For most businesses the sensible default is to allow the search and user-triggered agents, then make a separate, deliberate decision about training crawlers. There is a fair argument either way, and it depends on whether your content is your product. What matters for QA is that the decision was made on purpose and written down, because somebody will ask about it in six months.

Checklist (10)

• robots.txt written with explicit rules for search, user-triggered, and training agents individually
• The choice to allow or block training crawlers made deliberately and documented
• Your CDN and firewall rules actually match what robots.txt says you allow
• Cloudflare AI bot policies reviewed against their current default rather than the one you configured against last year
• Server logs show AI crawlers getting through, rather than being blocked or challenged
• Critical content readable without JavaScript execution
• Nothing that should be public sitting behind a login, paywall, or interstitial
• Sitemap current, submitted, and free of dead URLs
• Canonical and index tags correct, with no accidental noindex carried over from staging
• If you already publish an llms.txt file, keep it a short index rather than a copy of your pages, and do not expect it to do any lifting, because Google has said it does not use one (more on that in Step 8)

Search and index crawlers such as OAI-SearchBot, Claude-SearchBot, and PerplexityBot build the retrieval indexes that AI answers are assembled from. Block them and your pages cannot be retrieved, and if they cannot be retrieved they cannot be cited. This is the group people block by accident and then wonder where they went.

Step 8: SEO, GEO, and content quality

Ranking still matters, and so does being citable inside an answer.

SEO still drives visibility, but ranking is no longer the only outcome worth measuring, because a growing share of people get their answer without ever seeing a list of links.

Generative Engine Optimisation, or GEO, is the practice of structuring content and building authority so AI systems cite you inside their answers. You will also see it called AEO, LLMO or AI SEO. The naming is unsettled and the work is far less exotic than the acronym count suggests.

What Google said in May 2026. Search Central’s first official guide to generative AI features answered “does SEO still matter” with yes. AI Overviews and AI Mode draw on the same index, crawl and quality systems as blue links, so a page that cannot rank cannot ground an answer. Its mythbusting section dismissed several tactics sold at a premium for two years: llms.txt files, chunking content for machines, AI-specific markup, and rewriting for LLMs.

The genuinely new part is that the citation pool extends well beyond the top ten, so strong, specific content on page three can beat thin content in position one. That is either alarming or an opportunity, depending on how good your content is.

Checklist (18)

SEO basics

• Title tags and meta descriptions implemented and unique on every page
• Content matches what people are actually looking for, without keyword stuffing
• URLs readable, stable, and free of tracking clutter
• Related pages linked meaningfully rather than mechanically
• Logical heading hierarchy with one clear topic per section
• One version of every URL: pick www or non-www, force https, and keep trailing slashes consistent

Generative engine optimisation

• Each section answers its own heading in the first line or two
• Pages say something only you could say, rather than repeating what everyone else already published
• Comparisons and processes presented as tables and lists where appropriate
• Authors named, credentialed, and linked to real profiles
• Structured data added and tested, so search engines can read your key facts
• Your business name, address, and key facts match everywhere they appear online
• Search Console, analytics segmentation, and AI citation checks configured
• Bing Webmaster Tools verified as well, because Bing feeds several AI answer engines

Content review

• Spelling and grammar checked across the site
• Statistics, claims, and anything AI-assisted verified before publishing
• Images and video compressed, with appropriate alt tags
• Content reviewed periodically, and the date updated only when the content is

Google Search Central’s May 2026 guide answered “does SEO still matter” with yes, and dismissed several tactics sold at a premium for two years: llms.txt files, chunking content for machines, AI-specific markup, and rewriting for LLMs. The genuinely new part is that the citation pool extends well beyond the top ten.

Step 9: Agent readiness

Can a machine acting for a customer actually complete the job?

A growing number of your visitors are not people. They are agents acting for people: booking, buying, comparing, filling things in.

This step asks one question. Can a machine working on a customer’s behalf actually finish the job? Most of the groundwork is already done if you completed Step 3.

Checklist (9)

• The structure a screen reader or AI agent sees matches what people see on screen
• Buttons and links described by their action rather than their position
• Programmatic labels present on forms, with predictable and machine-readable error states
• No critical interaction depending on hover, drag, or precise motion
• The layout stays put while the page loads, so nothing moves under a click
• Prices, availability, and policies written out in text rather than shown only visually
• Structured data present for products, offers, and organisational facts
• Top three user journeys tested end to end with an AI agent
• Legitimate user-triggered agent visits not blocked by your security layer

Step 10: Integration and compatibility

Browsers, third parties, and the email nobody tests until it fails.

The pattern to watch for is the dependency you forgot you had. An integration that quietly breaks takes part of your site with it, and an email that never arrives is invisible until a customer complains.

Checklist (12)

Cross-browser testing

• All features work identically across different browsers
• Layout and styles consistent across browsers and versions
• Responsive designs adapt correctly in every browser, not just one
• Key flows tested in AI-assisted browsers

Third-party integrations

• Connections to third-party services tested for stability and security
• Data sent to and received from third parties verified as accurate and timely
• Third-party features perform their intended function inside the site
• If a connected service goes down, the page still works instead of breaking

Email and notification systems

• Notifications triggered by the correct actions
• Email and notification content checked for accuracy and completeness
• SPF, DKIM, and DMARC configured and passing
• Templates display correctly across devices, clients, and dark mode

Step 11: Legal, privacy, and AI disclosure

Current documents, honest disclosures, and consent that actually blocks tags.

Your site needs the right legal documents, particularly if you collect any user data. That means terms, a privacy policy, and whatever disclosures your jurisdiction requires, kept current rather than treated as a launch-day artefact.

Two of these are newer than the rest. Disclosing that a chatbot is AI, and labelling AI-generated media, are now requirements in a growing number of places.

Checklist (11)

• Privacy policy and terms comprehensive, current, accurate, and reachable from every page
• The cookie banner really does block tracking until someone agrees, checked in the browser
• Browser privacy signals like Global Privacy Control are respected
• Collection limited to what you need, with defined retention periods
• GDPR, UK GDPR, CCPA, CPRA, and applicable state law requirements reviewed
• The accessibility statement you published in Step 3 checked again here for legal accuracy and linked from the footer
• Chatbots and assistants clearly disclose that they are AI
• AI-generated images, video, and audio labelled where required
• Business identity in the footer: legal name, registered address, and company number where required
• Appropriate copyright notices on all content
• Your position on AI training use of your content stated and technically enforced

Step 12: Final pre-launch checks

The last line of defence, run on the day everybody is most tired.

This is the last line of defence, and it runs on the day everyone is most tired.

Regression testing confirms that recent fixes did not break something else. Cover all the critical paths, not just the area that changed, because the bugs that survive to production are almost always in the part nobody thought was affected. It matters most in the final week, which is exactly when people are least inclined to do it.

User acceptance testing puts real people in front of the site before it goes live. The single best improvement you can make: write your scenarios as goals rather than instructions. “Book a consultation for next Tuesday” tells you far more than “click Book Now, then select a date.” You are testing whether the site is usable, not whether people can follow directions. Watch where testers hesitate, and treat hesitation as a bug even when the task eventually succeeds. Then run those same goals through an AI agent, as in Step 9. Two audiences, one set of scenarios, twice the information.

The launch plan covers timing, staffing, technical readiness and communication. It should say how you go live and how you respond when something goes wrong, and it should name the specific person authorised to roll back.

Checklist (26)

Regression testing

• All critical functionality tested, not just the area that changed
• Tested both ways, with automated scripts and by hand
• Issues documented and fixes verified promptly

User acceptance testing

• A representative group of real end users engaged to test the site
• Scenarios written as goals rather than click-by-click instructions
• The same scenarios run through an AI agent
• Feedback collected, with fixes prioritised by what testers actually struggled with

Launch day technical checks

• Production robots.txt confirmed not to say Disallow: /
• No noindex tags carried over from staging
• Staging environment password-protected and excluded from indexing
• SSL certificate valid, correctly installed, with auto-renewal configured
• DNS records correct, with TTL lowered a day beforehand so the switch takes effect quickly
• Redirect map from old URLs in place and tested
• Every page on the old site accounted for: migrated, redirected, or deliberately retired
• Analytics and tracking firing correctly on the production domain
• Search Console verified, with the sitemap submitted
• Forms tested on production, with notifications reaching real inboxes
• A real payment processed and then refunded
• A full backup taken, and a restore actually tested
• Uptime and error monitoring live before launch rather than after
• Rollback plan written down, with one named person able to execute it
• Launch scheduled during low-traffic hours where possible

If the site sells anything

• Tax, shipping, and currency rules verified against real orders
• Order confirmation, invoice, and shipping emails all fire and read correctly
• Stock levels, stock status, and out-of-stock behaviour checked
• Refund, return, and cancellation flows tested end to end

Step 13: Access and handover

Who owns what, and whether any of it walks out the door with one person.

This is the step that bites hardest six months later, and almost nobody writes it down.

A site can be perfect and still be a liability if the domain sits in a freelancer’s personal registrar account, or the only person with Search Console access has left. Ownership is part of quality.

Checklist (6)

• Domain registrar, DNS, and hosting logins documented and owned by the business
• Domain auto-renew enabled, not just the SSL certificate
• Search Console, analytics, and tag manager access granted to more than one person
• Third-party service accounts held on company logins rather than someone’s personal one
• Nothing critical tied to an individual who could leave tomorrow
• Credentials stored in a password manager the team actually uses

Step 14: The first thirty days

The checks that cannot be done until real traffic arrives.

Launch is a milestone, not an ending, and a handful of checks simply cannot be done until real traffic arrives.

Core Web Vitals field data runs on a 28-day rolling window, which means your real performance scores do not exist on launch day. Check them at the end of the first month, then again at the end of the second, before drawing any conclusions about whether the optimisation work paid off.

Watch your crawl stats and server logs for both search and AI crawlers. Confirm they are getting through and receiving 200 responses, and that nothing at the CDN layer is quietly turning them away. This is where a Step 7 mistake becomes visible.

Check that form submissions are still arriving a week and a month in. Integrations expire, API keys rotate, and a lead form that silently stopped delivering is one of the most expensive bugs a marketing site can have.

And keep error monitoring in front of an actual human. An alerting system everybody has muted is not a monitoring system.

Checklist (4)

• Core Web Vitals field data checked at the end of month one and again at month two
• Crawl statistics and server logs watched for both search and AI crawlers receiving 200s
• Form submissions verified as still arriving a week and a month after launch
• Error monitoring kept in front of an actual human rather than a muted channel

Bonus: Running it with Atarim

We use AI to help build sites, so why not to check them? Atarim runs thorough passes for design, copy, SEO and accessibility, then actions the changes for you within your guardrails.

Checklist (12)

Set up

• Add the URL and let discovery run: it learns the brand, audience, and goals from the site, so read what comes back and correct anything it got wrong
• Set your approvals: what the specialists can change alone, and what waits for you

The launch pass

• Run a QA review of the site with Atarim, using this prompt *

Prompt

You are a senior designer running a pre-launch review of this website. Go through every template and check design consistency, copy and grammar, on-page SEO and metadata, WCAG 2.2 AA accessibility, broken links and redirects, and form behaviour. Give me one list ranked by severity, with the fixes you can make yourself marked separately from the ones I need to decide on.

* Did you know Atarim can fix many of the issues it surfaces on its own? Within your guardrails, of course.

Scheduled workflows, set before launch day

These live in the Workflows section in Atarim. Give each one a schedule and it runs on its own and reports back, so the checks keep happening after handover without anyone remembering to start them.

• Monthly design consistency sweep for drift after handover
• Recurring WCAG 2.2 AA check on every template, because new content breaks conformance fastest
• Weekly link, redirect, and form check
• Monthly Core Web Vitals and Lighthouse pull, lined up with the 28-day field data window
• Scheduled vulnerability scan across plugins and themes, with a backup before any update runs
• Recurring check on robots.txt, index tags, metadata, and structured data
• The thirty-day post-launch pass scheduled now rather than after a client reports something

For client sites

• Weekly check-in email on what was checked and what changed
• Monthly report sent before the invoice rather than after they ask

Two hundred and seven checks is a lot to carry on your own, and the honest answer is that almost nobody runs every one of them by hand on every launch.

That is exactly why it is worth adding your site to Atarim before the deadline gets close. Drop in the URL, let discovery learn the brand, set the guardrails you are comfortable with, and let the specialists take the first pass while you spend your attention on the decisions only a human should be making.

Add your URL and see what comes back before your client does.