Claude Code is useful for SEO when it works on a small change you can inspect. Give it a reviewed Google Search Console (GSC) export, one page, and the repository rules. Ask it for a plan before it touches the file. The finished job is a narrow diff plus a test and rollback note, not a vague promise to "optimize the page."
This workflow is for a marketer or SEO who has a developer-approved content repository and a GSC export. It does not require Claude Code to log into Search Console, publish a CMS entry, or deploy a release.
What you will finish with
Item | What it contains | Who approves it |
|---|---|---|
Evidence note | The selected page, queries, dates, and limits of the GSC export | SEO owner |
Change plan | One page-purpose hypothesis and affected files | Content and engineering owner |
Content diff | A small, inspectable edit | Reviewer before merge |
Release note | Preview check, rollback point, and later measurement date | Release owner |
Definition of done: the proposed change is easy to review and revert. Nothing is merged or deployed merely because the diff exists.
A GSC observation starts a change request. It does not settle the change by itself.
Start with one finding, not a keyword pile
Export a small GSC report for one URL and a defined date range. Include page, query, clicks, impressions, CTR, and average position. GSC calls this Search Analytics reporting; it is not a real-time rank tracker or proof that a particular URL is currently indexed. Keep the original export unchanged.
Choose a finding with a plausible page-level question. For example: a guide receives impressions for a comparison question, but the page never explains the comparison. Do not choose a query simply because it has a large number beside it.
Create an evidence file such as seo/evidence/widget-guide-2026-07.md:
# Evidence for /guides/widget-selection/
- GSC export: `gsc-page-query-2026-06-01-to-2026-06-28.csv`
- Page: `/guides/widget-selection/`
- Market and language: US, English
- Observation: the export includes comparison queries that the page does not answer.
- Not established: current index state, query intent for every searcher, and the cause of the change.
- Requested decision: add one sourced comparison section, or decide that another page should own that intent.Quality check: a colleague should be able to identify the source file, date range, page, and uncertainty without opening Claude Code. If the export mixes countries, devices, or subdomains, state that before asking for an edit.
Give the repository an explicit stop sign
Claude Code can inspect nearby files and create a diff. That is exactly why the rules need to be close to the work. Add the following to the repository's existing CLAUDE.md or the team's established Claude guidance location. Do not create a second instruction system if the project already has one.
## SEO content change policy
- Read `seo/evidence/` and relevant page files before proposing an edit.
- For SEO work, create `seo/plans/` before editing any content file.
- Do not run deployment, publish, merge, redirect, sitemap, robots.txt, or analytics-admin actions.
- Keep the change to the named page unless the user approves a wider scope.
- State which claim needs a source, which text is an editorial proposal, and how to preview or revert the change.
- Stop after the plan until a human says: "approve the plan for [file]."This file is useful guidance, not a replacement for branch protection or access control. Your repository and hosting platform must still enforce their own permissions.
Ask for a plan before you ask for prose
Open Claude Code in the repository and use this prompt. It deliberately asks for reasoning artifacts, not a finished rewrite.
Read `seo/evidence/widget-guide-2026-07.md` and the repository guidance.
Find the source file for the named page. Inspect only files needed to understand
its purpose, current headings, internal links, and build or preview command.
Create `seo/plans/widget-guide-comparison-plan.md`. The plan must include:
1. observed evidence and stated limits;
2. the page's present job and the proposed reader question;
3. exact files and headings that could change;
4. a source requirement for factual claims;
5. preview checks and a rollback method.
Do not edit content, run deployment commands, merge, publish, or change site
configuration. Stop after writing the plan.Expected output: a plan that names files and gives a reason for each edit. It may recommend no content change. That is a valid outcome when the page is not the right home for the query.
Recovery path: if Claude Code proposes a broad information architecture rewrite, ask it to return to one page and provide one reversible option. If it cannot find the page file, have it list the routes and evidence it inspected rather than guessing.
Review the plan as a page-owner decision
The review is not a grammar pass. Answer these questions:
Review question | A good answer looks like | Pause when |
|---|---|---|
Does the page own this question? | The reader would expect the answer on this page | Another page already has the clearer purpose |
Is the claim supportable? | The source is named or the wording is clearly editorial | The plan invents performance, product, or comparison facts |
Is the scope narrow? | One file or a small documented set of files | The plan quietly spreads into templates or navigation |
Can it be checked? | Preview command and visual/content checks are known | The plan has no way to see the result before release |
If the answer is yes, approve the exact plan and file scope. If it is not, revise the plan. A keyword report is evidence about observed searches, not permission to make a factual claim on the site.
Generate a small diff and inspect it like code
After approval, use a second prompt:
The plan in `seo/plans/widget-guide-comparison-plan.md` is approved for the
files it names. Make only those edits.
Preserve existing factual claims unless the approved plan replaces them with a
named source. Do not change global templates, redirects, robots.txt, sitemap
files, publishing settings, or analytics code. Show the final diff and a short
checklist of claims that need editorial confirmation. Do not commit, merge,
publish, or deploy.Read the diff line by line. Look especially for a title that promises more than the page delivers, a comparison table without sources, internal links that change the site's hierarchy, or a heading that duplicates another page's purpose.
A useful diff tells a reviewer what changed and why, without forcing them to reconstruct the investigation.
Preview, release, and measure separately
Run the repository's normal preview or test command. Compare the rendered heading structure, links, visible claims, metadata, and mobile layout with the approved plan. A content change can be textually correct and still break the page through a component or frontmatter mistake.
Only the responsible person should merge or publish. Record the release time, URL, source commit, and the review date you will use later. Do not ask Claude Code to declare success from the new diff. GSC and GA4 collect different kinds of data, and search performance can move for many reasons.
Google documents Search Analytics reporting separately from URL inspection. Keep those questions separate in your release note: one report can show a trend, while a URL inspection is about the current state of one URL.
A 20-minute review checklist
- [ ] The export has a known property, date range, dimension, and filter scope.
- [ ] The evidence note says what the data does not prove.
- [ ] The plan names a page purpose and a small file scope.
- [ ] A human approved the plan before the content edit.
- [ ] Every new factual claim has an editorial source check.
- [ ] The diff was rendered in the normal preview path.
- [ ] Merge and deployment remained separate, human-owned actions.
- [ ] The release note records a future review date rather than promising an outcome.
FAQ
Can Claude Code access my Search Console account?
Do not assume it can. This guide starts with an authorized export. If your team later connects a data source, document the connector's access, the property scope, and the allowed actions. A data connection should not imply publishing or deployment permission.
Should I ask Claude Code to rewrite the whole page from a GSC export?
No. Start with one question, one page, and a reviewed plan. A broader refresh may be right later, but it needs its own evidence, content brief, and editorial review.
Will a content diff improve rankings?
No tool can promise that. The purpose of the workflow is to make a defensible content decision and release it safely. Measure later, with the date range and limitations stated.
Author: Elise Morgan, 15-Year Editorial SEO Strategist at Auspia. Elise writes about content refreshes, editorial evidence, and changes teams can review before they publish.
