Agency Website QA Checklist: What to Test Before Launch

Set the QA rules before testing begins

Start with the website brief, approved sitemap, signed-off designs and final scope. These are the acceptance references. Without them, QA can drift into subjective redesign requests and the team cannot distinguish a defect from a new requirement.

Name one QA owner, one person authorised to accept the website and the environments being tested. Decide what blocks launch, what can be corrected during the support window and what belongs in a future scope.

1. Check scope, pages and content

Compare the build with the approved page list and requirements. Confirm that every promised page, template, component and integration is present. Then review the content as a visitor would see it rather than checking only whether text has been entered into the CMS.

• Every approved URL exists and uses the agreed naming
• Headings follow a clear hierarchy and no placeholder copy remains
• Names, addresses, prices, dates and contact details are accurate
• Images are sharp, correctly cropped and have useful alternative text
• Downloads open the correct final files
• Legal, privacy and consent copy has been approved by the responsible stakeholder

2. Test responsive layouts on real viewports

Do not treat mobile QA as a smaller desktop screenshot. Test common phone, tablet and desktop widths, landscape orientation and the spaces between named breakpoints. Increase browser text size and check long headings, navigation labels, form errors and CMS content that is longer than the design example.

• Navigation opens, closes and remains usable with touch and keyboard input
• Text does not overlap, clip or create unintended horizontal scrolling
• Buttons and form controls remain easy to select
• Tables, embeds and media adapt without hiding essential information
• Sticky elements do not cover headings, controls or consent notices
• Hover-only information has an equivalent for touch users

3. Follow every important user journey

Test journeys from their real entry points. A visitor may arrive on a service page from search, open the menu, read a case study and book a call without seeing the homepage. Confirm that each step makes sense and that the back button, external links and new-tab behaviour are predictable.

• Primary and secondary navigation links
• Service-to-case-study and article-to-service pathways
• Calls to action from each major page type
• Search, filters, pagination and empty states where included
• Custom 404 page and routes for removed or renamed URLs

4. Test forms beyond the success message

Submit every form with valid, invalid and incomplete data. Confirm what the visitor sees, what the receiving team receives and what is recorded in the CRM or other destination. The submission is not successful if the browser shows confirmation but the lead never reaches the business.

Use clear labels, instructions and errors, keep keyboard focus visible and make sure a failed submission does not erase safe information unnecessarily. W3C’s forms guidance explains why correctly associated labels and understandable feedback matter to keyboard, voice-input and screen-reader users.

• Required and optional fields are identified correctly
• Invalid email, phone and file inputs produce useful errors
• Spam protection does not block ordinary submissions
• Notifications reach the intended inbox with the required details
• CRM fields, source data and automation rules are correct
• Confirmation pages and emails use approved copy and links

5. Complete an accessibility review

Automated tools can identify some issues, but they cannot confirm that a page is understandable or that a journey works. Combine automated checks with keyboard testing, visual review and a basic screen-reader pass on the most important templates.

The W3C accessibility review covers practical checks including page titles, alternative text, headings, contrast, text resizing, keyboard access, visible focus, labels and errors. Treat these as a starting point rather than proof that the complete website conforms to an accessibility standard.

• Complete primary journeys using only the keyboard
• Check focus order, visible focus and that no component traps focus
• Confirm images have appropriate alternative text or are marked decorative
• Review heading structure, landmarks and descriptive link names
• Check text and interface contrast in normal, hover and focus states
• Verify motion can be reduced where it is not essential

6. Review technical SEO on the live domain

Run the final SEO review after the production domain is connected. Staging checks are useful, but they will not reveal a canonical that still points at the preview domain, a production noindex directive or a sitemap containing the wrong hostname.

• Each indexable page has a specific title, description and one clear H1
• Canonical URLs use the preferred HTTPS production domain
• Robots directives allow intended pages and exclude private or duplicate routes
• The XML sitemap contains absolute canonical URLs and excludes redirects and noindex pages
• Internal links are crawlable and point directly to final URLs
• Structured data matches visible content and validates without critical errors
• Redirects preserve relevant old URLs without chains or loops

Google recommends including the canonical URLs you want shown in search in the sitemap and using fully qualified URLs. Canonicals, sitemap entries, redirects and internal links should reinforce the same preferred destination rather than sending mixed signals.

7. Verify analytics and consent behaviour

List the actions the client considers meaningful before opening the analytics debugger. Then test those actions on the production site with the relevant consent choices. Page views alone do not confirm that booking, enquiry, download or ecommerce events contain the right parameters and fire at the correct moment.

• Analytics and tag containers use the production property
• Consent defaults and updates match the approved policy
• Key events fire once after successful completion—not on button clicks alone
• Internal traffic and test submissions can be identified
• No personal or sensitive information is sent in event parameters
• Search Console ownership and sitemap submission are confirmed

8. Check performance under realistic conditions

Test more than the homepage and do not rely on one laboratory score. Review representative service, article, case-study and conversion pages. Check how the experience behaves on a typical mobile connection, after consent tools load and when third-party embeds are requested.

• Hero media is appropriately sized and prioritised
• Images below the first viewport load only when needed
• Fonts do not create avoidable layout movement
• Third-party scripts are limited and loaded deliberately
• Interactive elements respond promptly after the page appears
• Performance is checked on the templates most likely to receive search and campaign traffic

9. Review security, privacy and operational ownership

Confirm HTTPS, platform updates, backups, administrator roles and recovery access. Remove temporary accounts and sample data. Check that private keys and environment variables are not exposed in the browser or repository, and document who owns each third-party service and renewal.

If the website collects personal data, the responsible business should approve what is collected, why it is needed, where it goes and how long it is kept. QA can verify the implementation, but it should not invent the organisation’s legal position.

10. Run the launch and post-launch checks

Create a short launch runbook with the sequence, owner and rollback decision for each important change. Immediately after launch, repeat the checks most likely to differ from staging: DNS and HTTPS, redirects, forms, analytics, indexability, integrations and transactional messages.

• A recent backup or known-good deployment is available
• The person authorised to approve launch is present
• DNS and deployment access has been verified in advance
• Critical journeys are retested on the public URL
• Monitoring and error reporting are checked after release
• The website handoff checklist and support window are ready

A concise agency website QA checklist

• Scope, pages and final content match the approvals
• Responsive layouts work between breakpoints and at larger text sizes
• Navigation, links, forms and integrations work end to end
• Keyboard, focus, labels, headings and alternative text have been reviewed
• Metadata, canonicals, robots rules, sitemap and redirects are correct
• Analytics, consent and key events are verified on production
• Representative templates have been checked for performance
• Access, backups, security and third-party ownership are documented
• Critical and high-severity issues are closed
• Launch approval, rollback and post-launch responsibilities are recorded

A useful QA process creates evidence for a launch decision. Keep the checklist, issue log and approvals with the project record, then carry the verified access and responsibilities into handoff. Agencies that use a white-label website delivery team should agree who owns each QA stage before production begins.