Claude Code pre-deploy checklist for website changes

Before any change made with Claude Code goes live on your website, run through eight checks: confirm what changed and that nobody else's work is mixed in, confirm the build passes, look at the change on staging, check the SEO basics, test forms and tracking, make sure no secrets went into the commit, get a person's approval, and know exactly how you'll roll back. If any check fails, the answer is "not yet."

This is a go/no-go gate, not a full testing plan. The detailed QA routine has its own guide, linked below. What follows is the short list a business owner, marketing manager or developer can tick off in a few minutes, with the prompt that runs the automated parts and the parts only a person can do. It reflects Claude Code as of October 2026.

How to use this checklist

Run it on the branch or pull request that holds the change, with the change already on a staging or preview copy. Claude can do the mechanical checks. A person does the judgment checks and the final approval. Keep the results with the pull request so there's a record.

For the full testing routine (cross-browser checks, accessibility, performance), see our guide to a QA routine before every deploy. For checks that run automatically on every pull request, see website QA with Claude Code in GitHub Actions.

1. Scope and history

The history check comes from a real mistake. When we rebuilt eseospace.com, one Claude Code session regenerated pages another had just edited, and those edits disappeared. Checking git log for changes you didn't make is now a standing rule before every deploy. More failures like this one are in our guide to common Claude Code mistakes on websites.

2. Build and automated checks

Ask for evidence, not a summary. Anthropic's best-practices page puts it this way: "Have Claude show evidence rather than asserting success." A pasted build log is evidence. "Everything looks good" is not.

3. Staging check in a real browser

Combining stylesheets on eseospace.com once exposed an unclosed brace in a theme file that swallowed header styles across the site. The lesson we recorded was to validate combined output in a real browser. No staging copy yet? Start with our guide to setting up a staging copy.

4. SEO and indexing

A stray noindex is the costliest small mistake on this list. Google says a page with noindex is dropped "entirely from Google Search results." It's easy to carry over from a staging copy. For redirect work, our guide to building a 301 redirect map explains how to test one.

5. Forms, tracking and money paths

6. Secrets and security

GitHub's guidance when secret scanning raises an alert: "rotate the affected credential immediately." Deleting the line from the next commit isn't enough, because the old commit still holds it. Our Claude Code security checklist covers the setup that prevents this in the first place.

7. Approval and the deploy itself

• A person approves. Someone who read the diff and saw the staging copy says yes, in the pull request. Branch protection with "Require pull request reviews before merging" makes this mandatory on GitHub.
• Claude doesn't deploy on its own. Anthropic's auto mode blocks "Production deploys and migrations" and "Merging a pull request no human has approved" by default. It does allow pushes to any branch, including main, so keep an ask rule on git push.
• Be deliberate about auto-merge. The desktop app can merge a pull request once all checks pass if you turn on its auto-merge option and GitHub auto-merge is enabled for the repository. GitHub's auto-merge waits only for the reviews and checks your branch protection requires, so leave it off unless a person's approval is one of them.
• Deploy at a time someone can watch. Not late on a Friday, and not when the person who knows the rollback is away.

8. Rollback plan and after-deploy checks

Rollbacks behave differently by host and plan. Vercel lets Hobby users roll back only to the immediately previous deployment, while Pro and Enterprise teams can roll back further. After a Vercel rollback, new pushes to the production branch don't go live until you undo it. On Netlify it's the opposite: with auto publishing on, the next deploy from git replaces the rolled-back version. Check your host's documentation.

A prompt that runs the automated parts

Paste this into Claude Code on the branch, in Manual mode, so you approve each command before it runs:

Before I deploy this branch: run the build and paste the last lines of output. Run the link checker. For every page changed on this branch, confirm it has a title, a meta description and exactly one H1. Search the built pages for noindex in robots meta tags. Confirm the sitemap includes every new URL. Run git log and list any commits on this branch that I didn't make. Report pass or fail for each check, with evidence. Don't edit any source files.

Adjust the commands to your project. Our templates page keeps a version of this prompt alongside a permissions file and other prompts for website work. The prompt covers the mechanical checks only. The browser checks, the form tests and the approval stay with people.

Conclusion

A pre-deploy checklist turns "Claude says it's done" into "we checked, and here's the evidence." Confirm scope and history, see the build pass, look at staging in a browser, protect your SEO basics, test forms and tracking, keep secrets out of the commit, get a person's approval, and know your rollback. It takes minutes, and it's the difference between a quiet release and a weekend of repairs. If you'd like a deploy process like this built into your site's workflow, our Claude Code development team sets it up as part of website projects. More guides are in our Claude Code Guide.

Frequently asked questions