A website QA routine to run with Claude Code before every deploy

A QA routine is the same set of checks, run the same way, before every deploy: confirm nobody else changed the site, build it, review the diff, compare SEO basics with the live site, test links and redirects, look at real pages in a browser, submit the forms, and have a person sign off. Claude Code can run nearly all of it for you if you package the routine once, as a skill with a few small scripts, so that one command runs every check and reports pass or fail. The routine catches problems. The person who approves the deploy still decides.

This guide is about building and running that routine with Claude Code. For a printable list of what to check, see our pre-deploy checklist. For running checks automatically on every pull request, see Claude Code in GitHub Actions for website QA.

The routine at a glance

Step 1: start with git, every time

The first check isn't technical. It's whether someone else changed the site while you worked. On eseospace.com, one session regenerated pages that another session had just edited, and the edits disappeared. Since then, the house rule is to check git history for changes you didn't make before any deploy. Our list of common Claude Code mistakes on websites describes this and other coordination failures.

Example prompt: Before anything else, show me the commits on main since this branch started, and any uncommitted changes. Flag any commit that touches the same files as this branch.

Step 2: build, then review the diff

Run the build and read the result. Then review what changed. Claude Code's /diff command shows the edits made so far alongside anything uncommitted, and /code-review reviews the current diff for correctness bugs in a fresh subagent. Anthropic's best practices explain why a fresh context helps: the reviewer "sees only the diff and the criteria you give it, not the reasoning that produced the change".

A person reviews: the diff summary, and asks about any file that changed without a reason. A content fix that also touches a template or a settings file deserves a question.

Step 3: compare SEO basics with the live site

A parity check compares each built page with the live version on the things search engines read. When we rebuilt eseospace.com, we compared titles, meta descriptions, robots directives, canonicals, structured-data types and H1s on old and new. After one fix for relative URLs, there were zero differences across all 217 pages checked. The same script works as a pre-deploy check: differences you meant to make should appear, and nothing else should.

Example prompt: For every page in the build that also exists on the live site, compare title, meta description, canonical, robots, H1 and structured-data types. Report only differences, and mark each as expected or unexpected based on this branch's diff. Flag any page that would become noindex.

An accidental noindex or a canonical pointing at the wrong page can remove pages from search results, so treat any unexpected change here as a reason to stop.

Step 4: links and redirects

Have Claude Code write a crawler for the built site that reports broken internal links, and a test that requests every redirect rule and checks the status code and destination. Run both every time, not only after big changes. Our guide to monitoring and fixing broken links explains what to do with the results.

Check: the report lists the number of pages crawled and rules tested. If the count is far lower than last time, the check itself may be broken. A script that silently processes nothing reports success.

Step 5: look at real pages in a real browser

A page can be correct in the file and broken on screen. Claude Code integrates with the Claude in Chrome extension to give it browser automation from the CLI or VS Code. Actions run in a visible Chrome window, and Claude can read console errors and the page's structure. Our guide to testing pages with Claude Code and Chrome covers setup.

Example prompt: Open the preview's homepage, one service page, one blog post, the contact page and the 404 page. For each, report console errors, check that the menu, accordions and any popup open and close, and repeat at phone width. Take a screenshot of each at both widths.

Pick pages by type, not just the homepage, and include the second and third pages any script generated. If you record a session, Anthropic warns that the recording "captures everything visible in the browser, including account details on logged-in pages", so review it before sharing.

Step 6: forms, tracking, accessibility and speed

• Forms. Submit a test entry on staging and confirm it arrives where it should. When Claude Code meets a CAPTCHA in the browser, it pauses and asks you to handle it, so form tests often need you there.
• Tracking. Confirm the lead event fires once per successful submission, using GA4's DebugView.
• Accessibility. Run an automated checker on sample pages and compare with the last release. The W3C notes that "Human judgement is required", so a clean report isn't proof, and keyboard-only and screen-reader checks still need a person.
• Speed. Spot-check a few pages in a lab tool and compare with the last release. Google's Core Web Vitals targets are an LCP within 2.5 seconds, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of real visits, so lab scores are a warning light, not the verdict.

Step 7: package it as a skill and a hook

Once the steps work, make them one command. A skill is a SKILL.md file of instructions Claude Code can follow on request. Put it in .claude/skills/qa/ and commit it, and anyone on the team can run /qa. Anthropic suggests a skill "when you keep pasting the same instructions, checklist, or multi-step procedure into chat". A short excerpt:

---
description: Pre-deploy QA for this site. Run before every deploy.
disable-model-invocation: true
---
1. Show commits on main since this branch started.
2. Run npm run build. Stop if it fails.
3. Run scripts/parity.mjs and scripts/links.mjs. Report differences only.
4. Write qa-report.md with pass or fail for each check.

With disable-model-invocation: true, only you can start the skill, which suits a routine that ends in a deploy decision. Our explainer on Claude Code skills covers the other options. One more detail: if a project has a skill named verify, Claude Code (v2.1.286 or later) tells Claude to run it right before each commit, except for changes to docs or tests. That only works if Claude is allowed to invoke the skill, so don't set disable-model-invocation on a verify skill.

For a check that must never be skipped, add a hook. A Stop hook can run your build when Claude finishes a turn and block the turn from ending until it passes. Our guide to hooks for website projects shows how.

Step 8: sign off, deploy, and check the live site

The routine ends with a short report: each check, pass or fail, and anything unexpected. A person reads it, looks at the screenshots, and approves the deploy. Claude Code shouldn't deploy to production on its own. Anthropic's auto mode blocks production deploys by default, but it also allows pushes to the default branch, so if a push to main deploys your site, add an ask rule for git push so a person confirms it.

After the deploy, run a quick smoke test on the live site: the changed pages load, forms submit, and nothing returns an error. If a change looks missing, check the build output and git log before redoing work. On our own site, a CDN once served a stale copy after a deploy, which made a finished change look missing.

Conclusion

A good QA routine is boring on purpose: the same checks, in the same order, before every deploy, ending with a person's approval. Claude Code makes it cheap to run by turning each check into a script, packaging them as a skill, and reporting results you can read in a minute. If you'd like a routine set up and run for you as part of ongoing care, see our website maintenance plans. More guides are in our Claude Code Guide.

Frequently asked questions