Using Claude Code in GitHub Actions for website QA

Claude Code GitHub Actions lets Claude review every pull request on your website's repository before it merges: checking changed pages against your SEO and content rules, flagging broken logic in templates, and answering when someone types @claude in a comment. It runs on your own GitHub runner, it costs GitHub Actions minutes plus Claude usage, and it works best as a second reviewer alongside your scripted checks, never as the thing that decides what ships.

The integration is a GitHub Action published by Anthropic, anthropics/claude-code-action@v1. A GitHub Action is a job that runs automatically when something happens in a repository, such as a pull request being opened. A pull request (PR) is a proposed set of changes that someone reviews before it merges into the main branch, which on most modern website setups is what triggers a deploy.

This guide covers how website teams use it for quality assurance (QA), how to set it up, what it costs and the guardrails to put in place first. It assumes your site's code already lives in GitHub. If it doesn't, that's the first project.

What it does for a website team

Most website problems that reach production are small and boring: a template change that drops the H1 on every service page, a renamed URL with no redirect, a canonical tag pointing at staging, a phone number updated in the footer but not in structured data. Scripted checks catch some of these. A reviewer who reads the change in context catches others. Claude in a workflow can do some of that reading on every PR.

Typical website QA jobs:

• PR review. Read the diff, check it against the rules in your CLAUDE.md, and post inline comments where something looks wrong.
• On-demand questions. A reviewer comments "@claude does this change affect any page's canonical or robots tags?" and gets an answer on the PR.
• Small fixes from a comment. "@claude add the missing alt text flagged above" produces a commit on a branch for review.
• Scheduled reports. A weekly job that summarizes the week's commits and open issues, or runs an SEO skill against the latest build and writes the results to the run log.

For the SEO checks themselves, such as titles, redirects and schema, see Claude Code for technical SEO. This article is about running them automatically.

Interactive mode and automation mode

In automation mode with a plain-text prompt, Anthropic's docs say Claude "has no shell or GitHub API access until you grant the tools the prompt needs." That default is useful: you decide exactly what a scheduled job can touch.

Setting it up

Anthropic's GitHub Actions documentation describes two routes. Both need admin access to the repository.

1. Install the GitHub CLI and sign in, then open Claude Code in the repository.
2. Run /install-github-app. It installs the Claude GitHub App, saves your credential as a repository secret and prepares a pull request with the workflow files you select, including an optional review workflow.
3. Choose a credential. Either an API key from the Claude Console, saved as ANTHROPIC_API_KEY, or a subscription token from claude setup-token, saved as CLAUDE_CODE_OAUTH_TOKEN, available on Pro, Max, Team and Enterprise plans.
4. Review and merge the workflow PR. Read the workflow files like any other code before merging.
5. Test it by commenting @claude on a test PR.

The manual route installs the app, adds the secret and copies an example workflow into .github/workflows/ yourself. Use it when you want full control of the files. For a team with several repositories, the docs recommend an organization-level secret using a Console API key, because an OAuth token "is tied to the subscription of the person who ran claude setup-token."

Put your rules where the workflow can read them. Claude reads the repository's CLAUDE.md on every run, so the SEO and content rules in it become the review criteria. Our guide to writing a CLAUDE.md for a website covers what to include, and our templates page has a reusable SEO-check skill. A skill saved in .claude/skills/ can be run from a workflow by passing its name as the prompt, as long as the workflow checks out the repository first.

A practical QA pipeline for a website

Claude reads and judges. Scripts measure. A sound pipeline uses both, in this order:

1. Build. The site must build. A failed build stops everything.
2. Scripted checks. Link checker, HTML validation, a check that no page has an accidental noindex, and any tests you have. These are repeatable and cheap.
3. Claude review. Claude reads the diff with your CLAUDE.md rules and comments on what the scripts can't judge: a title that no longer matches the page, a redirect that sends an old URL to the wrong topic, an H1 removed from a shared template.
4. Preview deploy. If your host builds a preview for each PR, a person looks at the changed pages on real screen sizes.
5. Human approval and merge. A person approves the PR. Merging to the main branch triggers the production deploy through your host, not through Claude.

If your deploys run from GitHub to a host such as Vercel, our guide to deploying GitHub projects to Vercel shows how previews and production deploys connect to branches.

The managed alternative: Code Review

If you don't want to maintain workflow files, Anthropic runs a separate service called Code Review. According to its documentation, it is "in research preview, available for Team and Enterprise subscriptions." Multiple agents analyze each PR on Anthropic's infrastructure and post findings as inline comments, tagged by severity. Findings "don't approve or block your PR", so your existing review process stays in charge. You can add a REVIEW.md file at the repository root for review-only instructions.

On other plans you can still review a diff locally with the /code-review command. GitLab users have a separate Claude Code integration for GitLab CI/CD, which is in beta and maintained by GitLab.

What it costs

Each workflow run uses two resources. The first is GitHub Actions minutes on GitHub-hosted runners, priced by GitHub. The second is Claude usage: tokens billed at API rates when you authenticate with an API key, or your subscription's usage when you use an OAuth token. Larger diffs, larger codebases and longer prompts cost more. Plan prices and API rates are in our guide to Claude Code pricing.

For the managed service, a rough sum helps. Hypothetical example: a site with 40 PRs a month, each reviewed once, at Anthropic's stated average of $15 to $25 per review, would spend somewhere around $600 to $1,000 a month on Code Review. Reviewing on every push multiplies that by the number of pushes, which is why the docs offer a manual mode and a spend cap.

Anthropic's docs list ways to keep workflow costs down:

• Write specific @claude requests so Claude needs fewer turns.
• Keep CLAUDE.md concise, since Claude reads it on every run.
• Set --max-turns in claude_args to cap each run.
• Set workflow-level timeouts and use GitHub's concurrency controls to limit parallel runs.

Guardrails to set before the first run

• Secrets in GitHub Secrets only. The docs are direct: "Never commit API keys or OAuth tokens directly to your repository." Keep deploy keys and hosting credentials out of the Claude job entirely.
• Minimum workflow permissions. The docs' own review example asks only for read access to contents, pull requests and issues, plus the token permission the action needs to authenticate. The official Claude GitHub App grants a broad permission set; organizations that need less can create a custom app with only Contents, Issues and Pull requests.
• People create and merge PRs. According to the action's security documentation, in its default configuration Claude commits to a new branch and "the user must click the link and create the PR themselves." Keep branch protection on the main branch so a person approves every merge.
• Know who can trigger it. Only users with write access can trigger runs on PR and issue events, and bots are rejected unless you list them. Don't loosen these settings on a public repository.
• Treat contributed content as untrusted. The security docs warn about "hidden markdown" in content from outside contributors, a form of prompt injection. The action strips HTML comments, invisible characters and similar tricks, but the docs say "new bypass techniques may emerge", so read outside contributions yourself before asking Claude to process them.
• Never let the job deploy to production. Claude can comment, suggest and commit to a branch. Production deploys stay with your host's normal process after a person merges.

Our guide on whether Claude Code is safe for a live website covers permissions and prompt injection beyond CI.

Conclusion

Claude Code in GitHub Actions gives a website team a reviewer that reads every pull request against the team's own rules, at the cost of Actions minutes and Claude usage. Put it after the build and your scripted checks, keep credentials in GitHub Secrets, give it the minimum permissions, and keep a person approving every merge and deploy. AI review catches things people miss, and misses things people catch, so it adds to human review rather than replacing it. If you'd like a QA pipeline like this set up on your site, our Claude Code consulting covers automated checks and the review workflow around them. More guides are in our Claude Code Guide.

Frequently asked questions