Laptop, tablet, and monitor on a wooden desk next to a printed handoff QA checklist.

Website pre-handoff QA checklist

Before a website goes to the team that will run it, use this handoff QA checklist to check what works, what changed, and what to do when something fails.

Content and claims

Pages that look finished are not proof of readiness. The people responsible for content, leads, accounts, and support need these answers, and the checks belong on the saved site, not only in a design file.

  • Read every important page as a first-time visitor. Can you tell who it is for, what it offers, and what action comes next?
  • Check names, service details, locations, hours, prices, policies, team information, and dates against current approved sources.
  • Remove placeholder copy, internal notes, unsupported testimonials, fabricated results, and obsolete offers.
  • Check page titles and descriptions for unique intent. The title should match the visible page rather than promise a topic the body does not answer.
  • Confirm that images, logos, quotes, and project examples have permission to appear, with suitable alt text or a decorative decision.

Navigation and links

  • Follow the main navigation, footer, breadcrumbs, and in-page links on desktop and mobile.
  • Check that each CTA says what happens next and reaches the intended form, calendar, phone number, or page.
  • Test downloads and external destinations. Make the handoff clear when a visitor leaves the website.
  • Review redirects from replaced pages and make sure important old links do not strand visitors.
  • Check empty states, missing results, and expired event or offer pages, not only the happy path.

Forms and connected systems

  • Send a valid test inquiry and confirm it reaches the right destination with the information the team needs.
  • Test required-field errors, invalid input, duplicate submissions, confirmation, and delivery failure.
  • Confirm that the form does not request more personal information than the receiving process needs.
  • Test CRM, scheduling, payment, email, or automation handoffs under the actual approved accounts. A success message on the site is not proof that a downstream system received the event.
  • Name the person who will notice and resolve a failed handoff.

Mobile, accessibility, and performance

  • Test representative small and large screens, long content, missing media, and slow connections.
  • Use the site with a keyboard. Check focus visibility, menu operation, form labels, errors, and modal behavior.
  • Check text contrast, heading order, link names, image alternatives, captions where needed, and reduced-motion behavior.
  • Review real page speed and layout stability on the pages most visitors use. A fast template does not prove every image-heavy page performs well.

Search and measurement

  • Confirm the intended canonical URL, index/noindex decision, sitemap inclusion, redirects, and robots access for each page type.
  • Check structured data against visible, verified page facts. Do not add markup for offers, reviews, or FAQs that are not genuinely present and eligible.
  • Verify analytics events or form goals with a test, consent handling, and the destination where the team will inspect results.
  • Search for duplicate page purpose across service, industry, resource, and location routes. Consolidate pages that answer the same question without adding value.

Ownership and recovery

  • Record who can edit the site, who owns each connected account, and how access is transferred securely.
  • Provide a content update path for changing services, people, prices, events, and business details.
  • Confirm backups, restoration responsibilities, update procedures, monitoring, and the support route that applies to this project.
  • Give the receiving team a short list of known limitations and deferred work. A handoff should not disguise an untested integration as complete.

A useful final walk-through

Ask a person who was not involved in the build to complete the primary visitor task on a phone. Then ask the receiving team to update one piece of content and trace one test inquiry. Record the result, fix the failure, and repeat the test. A signed-off checklist is strongest when it points to observed evidence.

If the project is still a design prototype rather than a working build, use the stakeholder prototype review guide for task-based feedback first. This checklist belongs at the later handoff gate.

If the site is not yet ready for launch, use the results to prioritize the next fix. Website care begins with clear ownership and a dependable handoff, not with a promise that nothing will ever change.

The other Checklist.

There are 2 in this format. If this one is not the one you need, the other one is here in full.

You are reading this one.

Website Pre Handoff QA Checklist

The final pass that catches broken links, missing alt text, and mobile bugs before a client sees the site.

Same format: Checklist.

Brand Launch Readiness Checklist

Every asset, link, and detail you need locked before a brand goes live.

Launches fail on small misses, not big ideas. This checklist covers logos, fonts, favicons, social handles, meta tags, and the tracking that proves the launch worked.

Back to top
Share to...