Claude Code Constitutional Guardrails for SEO

Claude Code constitutional guardrails for SEO scripts: pair Claude's intended behavior with permissions, tests and review so automation stays safe.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Claude Code is Anthropic's agentic coding tool. Its overview describes it as an AI-powered coding assistant that understands your codebase and works across multiple files and tools, and it runs in the terminal, IDEs, a desktop app and the web. For SEO teams it is a practical way to build scripts that pull Search Console data, audit pages, generate structured data, check redirects or prepare content updates. This skill covers building that kind of Claude Code SEO automation with guardrails at three levels.

The first level is the model's own behavior, described in Anthropic's constitution. Several passages bear directly on scripting. The constitution uses a coding example to explain final goals: if asked to "edit my code so the tests don't fail" and no good general solution exists, Claude should say so instead of special-casing the tests. It asks Claude to prefer cautious actions in unclear situations ("If in doubt, don't"), to avoid side effects its principals would not sanction, and to raise concerns before starting a task instead of abandoning it midway. It also says instructions found inside tool results, documents and search results should be treated as information, not as commands.

The second level is the tool. Claude Code's permissions documentation is direct about the split: permission rules "are enforced by Claude Code, not by the model," and instructions in your prompt or CLAUDE.md "shape what Claude tries to do, but they don't change what Claude Code allows." Allow, ask and deny rules decide which commands and file edits run without approval, and plan mode lets Claude explore and propose without editing source files. The constitution guides intent; permissions set hard limits.

The third level is your own process: tests that check script output, review of every change before it goes live, and search guidelines that decide what the scripts should produce at all. Google's spam policies are the relevant limit for SEO scripts, especially scaled content abuse and keyword stuffing. A script that is safe to run can still produce pages Google treats as spam.

For the constitution itself, see the parent method.

How It Works

Project context lives in a CLAUDE.md file. The memory documentation describes CLAUDE.md files as markdown files with persistent instructions that Claude reads at the start of every session, and a project CLAUDE.md can be shared with the team through source control. For an SEO repository it should state what the scripts are for, which data sources are authoritative, which outputs need human review, and the rules that matter, each with a reason. That context lets Claude make sensible choices when a task leaves something unstated, which is how the constitution expects it to work.

Permissions enforce the limits that must hold regardless of what anyone writes in a prompt. Rules are evaluated deny first, then ask, then allow (permissions). A typical SEO project allows reading the repository and running tests, asks before network calls to external APIs, and denies commands that would publish to production or touch credentials. Publishing then happens through your normal deployment process, with a person approving it.

Verification closes the loop. Claude Code's best practices recommend giving Claude a way to verify its work, such as tests, a build or a script that diffs output against a fixture, and recommend exploring and planning before coding. For SEO scripts, verification means fixture tests on sample pages, schema validation for structured data, and dry-run modes that write proposed changes to a file for review.

The constitution's guidance on honesty and effort matters here too. It asks Claude not to engage in "deceptively sandbagging" a response, meaning quietly delivering lower-quality work while implying it is the best possible, and to be transparent when it is not doing part of a task. Anthropic's prompting guide notes that Claude can sometimes focus too heavily on making tests pass and recommends asking for general solutions that do not hard-code test values. Put that expectation in CLAUDE.md so a failing check produces an explanation instead of a workaround.

Finally, treat scraped content as untrusted input. Scripts that crawl competitor pages or read search results feed Claude text written by others, and some of it may contain instructions. The constitution's rule is that such instructions are information to consider, and your permissions ensure that even a misread instruction cannot trigger an action you have not allowed.

Step-by-Step Guide

Step 1: Define the task, its output and its limits

Write down what the script should do, what it reads, what it writes, and what it must never do. Say who reviews the output and where it goes afterward. Include the search-quality limit: for example, the script updates titles on existing pages and never creates new pages. This definition becomes the first section of CLAUDE.md and the basis for your tests.

Step 2: Write the project CLAUDE.md

Create a CLAUDE.md at the repository root, as the memory documentation describes, with the purpose of the project, the authoritative data sources, the commands to run tests, and the rules with their reasons. Add the expectation that failing tests are reported and explained, never forced to pass with special cases. Note that scraped or fetched content is untrusted. Commit it so every teammate's sessions start from the same context.

Step 3: Configure permissions for the limits that must hold

Set allow, ask and deny rules in the project settings following the permissions documentation. Deny commands that publish, deploy or read secrets. Require approval for network calls to APIs that change data. Allow reading, testing and writing to a dedicated output directory so routine work stays fast.

Step 4: Plan before building

Start in plan mode so Claude reads the codebase and proposes an approach without editing files. Review the plan for scope, data handling and side effects. Ask Claude to raise any concerns about the task now, since the constitution notes that concerns are best raised before a task starts. Approve the plan or adjust it before any code is written.

Step 5: Build with tests and a dry run

Ask Claude to write the script together with fixture-based tests: sample pages in, expected output out. Include a dry-run mode that writes proposed changes to a file instead of applying them. Have Claude run the tests after each change, following the best practices guidance on giving it a way to verify its work. Read the diff yourself before moving on.

Step 6: Check the output against search guidelines

Run the dry run on real data and review the proposed changes against Google's spam policies and its guidance on accurate generated titles, descriptions and structured data. Look for repetitive text, keyword stuffing and anything that would create near-duplicate pages. Fix the script or the prompt it uses where the output falls short. Only then consider applying changes.

Step 7: Apply through review and record results

Apply approved changes through your normal publishing or deployment process with a person signing off. Keep the dry-run file as a record of what changed. Watch Search Console after the change and note the outcome in the repository. Update CLAUDE.md and the tests with anything you learned.

Best Practices

• Put hard limits in permissions and soft guidance in CLAUDE.md. The permissions documentation is explicit that instructions do not change what Claude Code allows, so anything that must never happen belongs in a deny rule.
• Explain every rule in CLAUDE.md. The constitution favors judgment informed by reasons, and a reason tells Claude how to handle cases the rule did not anticipate.
• Use dry runs by default. Writing proposed changes to a file makes every change reviewable and reversible before it touches the site.
• Test with fixtures from your own site. Real sample pages catch edge cases such as missing headings, duplicate titles and unusual templates.
• Treat fetched pages as data. Scraped content can contain instructions; the constitution tells Claude to treat them as information, and your permissions make sure they cannot trigger anything you did not allow.
• Keep sessions focused. The best practices note that the context window fills quickly, so clear it between unrelated tasks.

Common Mistakes

• Relying on the prompt for safety: A line in CLAUDE.md saying "never deploy" shapes what Claude tries to do but cannot stop the command from running. Add a deny rule for the deploy command as well.
• Accepting passing tests at face value: Tests can be made to pass by special-casing them. Ask for general solutions, read the diff, and check that the tests assert real behavior.
• Letting scripts publish directly: Automated changes to live pages without review turn small bugs into site-wide problems. Route every change through a dry run and approval.
• Building a page generator by default: Scripts that create many pages from keyword lists can produce what Google calls scaled content abuse. Aim automation at improving and maintaining existing pages, and treat new pages as individual decisions.
• Skipping the plan: Jumping straight to code can solve the wrong problem. Use plan mode for anything that touches multiple files or external data.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Claude's Constitution

Related Skills

• Automate SEO with Claude: Reasoning Principles
• Claude Constitutional Reasoning in AI Workflows
• Claude Content Optimizer: Evaluate Against the Constitution

Sources

• Claude Code docs: Overview
• Claude Code docs: Memory and CLAUDE.md
• Claude Code docs: Configure permissions
• Claude Code docs: Best practices
• Anthropic: Claude's Constitution
• Claude docs: Prompting best practices
• Google Search Central: Spam policies

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.