How to Automate a Content Audit and Refresh With Claude
How a Claude content audit workflow picks which blog posts to refresh, sizes the update, and waits for human approval. Steps, tools and limits.
SE Ranking's product ships a lot of updates. The team couldn't keep up with updating the blog posts that describe features, or even with tracking which posts those updates affected. The audit and refresh workflow in Claude exists to fix that. It is built around three questions it has to answer for every page before anyone edits it: why this page now, how large the update should be, and which parts must stay as they are.
We built the two plugins behind it, content audit and content update, as part of my work at SE Ranking. This article goes through how the workflow runs and why it is set up this way, and then shows how to start with the public version of the plugin. SE Ranking also covered the workflow in its video 3 Claude Use Cases SEOs Should Copy Starting Yesterday (Oct 20, 2026). The audit and refresh part starts at 04:24.
One thing to know before reading on. The video shows the internal setup, which runs on a Notion inventory, Slack threads and several other connections. The plugin you can install today, content-refresh, is a simplified version of it: no databases and no channels, only chat, two connectors and plain markdown files. The sections up to "Limits" describe the internal setup. The section "Start with the content-refresh plugin" covers what you can run yourself and how it differs.
What the workflow replaced
Before the workflow, every refresh was manual: reading the post, analyzing its performance, fact-checking it, checking news and product updates, and so on. It was a long process, and the product updates were the part nobody could keep up with.
Now the agent does that work. The person's job is to read the result, verify it and approve it. The team estimates this cuts the time spent preparing a blog refresh brief by up to 80%.
What the internal setup runs on
- SE Ranking: Rankings, SEO and AI visibility data
- Google Search Console: Clicks and positions
- Notion: Blog database and drafts
- Slack: Review and approval
- Firecrawl: Live page content
- Claude: The agent that connects everything
Claude runs two agents on top of these. The audit agent decides which pages need attention. The update agent prepares the refresh.

Start from an inventory instead of a fresh pull
The audit works from a structured blog inventory in Notion. Each row holds the last update date, clicks, impressions, AI visibility, rankings, backlinks, target keywords and selected business metrics. Because that data is already there, the agent doesn't pull fresh numbers for every URL on every run.
It runs in two modes:
- On the whole blog database, where it narrows the list to five priority pages at most.
- On a list of 1 to 10 URLs, where it skips the shortlist and goes straight to the deep analysis.
The five-page limit protects quality. With more pages in one run, Claude runs out of context, and both the audit and the content get worse.
In the first mode, the agent filters pages by category, age, AI visibility and Search Console performance. Pages that pass get a closer look at performance data, product updates, business metrics and cannibalization risks.
Score the pages and keep a reason for each pick
The agent combines these signals and scores each page with configured weights. It also fills dedicated slots for SEO decay, AI visibility opportunities, product updates and business priorities, so the shortlist is not only the pages with the steepest traffic decline. The weights and the proportions between slots can be set to match what a business or an SEO team cares about.
That configuration did real work early on. The agent kept proposing news posts for a refresh, because news content loses relevance faster than anything else on a blog. Adjusting priorities and weights fixed it.
Every selected page comes with a stated reason. The run can stop here, which lets someone review the shortlist before any audit starts.
Check what traffic can't show
The audit also reads the team's Slack channels for SEO news and product updates. This part exists because of the product pace described above. A page can rank well, bring steady traffic and still be wrong: it may describe an old version of the product or skip a feature launched since. A traffic chart won't show that, at least until the traffic drops.
The content audit guides I read for this article score pages on search data, AI visibility data or content quality. I didn't find internal product changes used as a trigger in any of them.
Commit to one cause per page
For each shortlisted post, the agent reads the live page, pulls the SERP and runs six analyses: deep research, product mentions, internal links, People Also Ask, competitor structure and AI visibility. Current rankings, queries, traffic trends and AI visibility come from SE Ranking and Search Console. Then the agent commits to one reason the page is losing and shows the evidence for it.
Stop for human review
The audit sends one digest to Slack. It covers:
- the page
- why it was picked now
- how big the update should be
- what to change
- what stays untouched
Then the run stops.

The audit and update sessions run locally on the person's computer, so Slack is the only shared place for the process. The digest and the update proposals go to a thread where the whole team can see them. Anyone can leave a comment there, and the agent takes it into account. The go-ahead itself is given in Claude by the person running the session, and thread replies are collected as comments and overrides. Once the audit is approved, Claude pulls that feedback in and the update starts. This is where the two plugins meet: the audit ends and the update begins.
The "what stays untouched" line does real work. If a page already ranks, rewriting all of it because it's old can do more harm than good. The plan fixes what's outdated and keeps the rest.
Size the update before writing it
The update agent starts with fresh page, SERP and AI visibility data. It also takes competitor research, product and industry updates, AI answer gaps and the team's comments from the thread. Then it picks the size of the update. After a major product release, that can be a full rewrite. If rankings are stable but clicks are low, it may change only the title and meta description.
Only the approved sections change. Locked passages, links and schema stay as they are.
Fact-check and edit in one pass
Fact-checking and editorial review are merged into a single fix list that covers facts, editorial rules, brand voice and a check that locked content didn't change. Only flagged sections are rewritten, never the whole article.
The fact-checker tests its own tools before it starts. If they fail, the result is marked "uncertain" and goes to a person instead of passing as verified.
Where the refresh ends up
The refresh lands in Notion with a change brief, a preservation checklist, a summary and the final article.

The agent never publishes to the live blog. A person does. A notification goes to the same Slack thread, so the proposal, the approval and the draft stay in one conversation.
Re-check after about eight weeks
About eight weeks later, the workflow checks each page again: clicks, rankings, average position and AI visibility. The result is written back to Notion, so the team can see whether the update worked or the page needs a bigger change.
Before-and-after rankings for refreshed pages aren't part of this article. The time estimate in the section above is the one number the video gives for this workflow.
Limits
- The audit starts from the Notion inventory, so its picks are only as current as that inventory.
- A whole-blog run returns five pages at most, to keep Claude's context from degrading the work.
- The product-news signal needs product updates posted somewhere the agent can read. At SE Ranking that is Slack.
- Sessions run locally, so team collaboration goes through the Slack thread.
- The fact-checker can return "uncertain".
- A person reviews every refresh and publishes it.
Start with the content-refresh plugin
SE Ranking publishes a standalone version of this flow in seranking/marketing-automation-plugins. According to the plugin's README, the internal pipeline spans two plugins, about 30 subagents, a Notion config database, Slack approval threads and BigQuery checks. The public content-refresh plugin keeps the thinking and drops that infrastructure. It has two skills:
/refresh-audit → audit report + plan → you approve in chat → /refresh-update → refreshed drafts
The marketplace also contains content-skills, which has a different pipeline for content briefs, editorial plans and social packs, with Planable. For the audit and refresh flow described here, install content-refresh.
What the plugin does
/refresh-audit takes 1 to 10 URLs, or a domain, and never writes article content. For each page it:
- Scrapes the live page with Firecrawl and extracts the outline, word count, dates, claims with numbers, links and schema types. A scrape that looks like a JS failure or a paywall teaser is flagged [SCRAPE SUSPECT] and cannot justify a "thin content" diagnosis on its own.
- Scans for stale facts: years two or more behind the current one, "as of" phrasing, dead or redirected external links.
- Checks which keywords the URL ranks for in SE Ranking and confirms or corrects the target keyword.
- Pulls the SERP for that keyword: the top 10, who holds the featured snippet and People Also Ask, whether an AI Overview is present.
- Scrapes the top 2 or 3 competing pages and lists the subtopics at least two of them cover that your page lacks.
- Collects question keywords and, if your SE Ranking plan includes AI Search, checks whether the brand is cited for related prompts.
- Researches current replacements for every stale fact, with a source URL for each, in a per-page research file.
- Checks whether another page on the same domain ranks for the same keyword.
- Optionally pulls real clicks, impressions, CTR and position from a Google Search Console MCP, plus an indexing check. If the URL isn't indexed, the report leads with that, because a rewrite won't fix a technical block.
Then it diagnoses one primary cause, with an optional secondary one and a confidence rating. The possible causes are staleness, competitor_gap, intent_shift, serp_feature_loss, ai_visibility_loss, cannibalization and never_performed.
It recommends the lightest update depth that fixes that cause:
- metadata_only: Meta title and description. The body stays identical.
- micro_update: In-place edits: stats, years, dates, sentences, an H1 reword that keeps the target keyword.
- section_refresh: Edits inside existing sections, plus FAQ entries.
- substantial_update: New H2 sections, reordering, removing sections.
- full_rewrite: All sections regenerated. Needs explicit confirmation.
The outcome isn't always an update. leave_alone, merge (with a target URL) and prune are valid results.
Before any editing, the plan locks what already works: the URL, the target keyword in the H1, passages that win featured snippets or AI citations (verbatim), working internal links and schema types. Each page also gets a change map that marks every section as keep, modify, add or remove, with a reason and a link to the research entry behind it.
The approval happens in chat. For each page you approve, skip, change the depth or add notes. Reviewer notes outrank the saved plan. Everything is written to refresh-plan.json.
/refresh-update then re-scrapes each approved page and drops change-map operations that the live page already made moot. It executes the plan at the approved depth and no further. Before delivery it runs three checks:
- Fact check. Every added or changed number, date, name and quote must trace to a source URL in the research file. What can't be verified is reverted or marked [NEEDS SOURCE].
- Cliché sweep. It removes a fixed list of stock phrases, plus any banned words from your voice notes. The list is English-only.
- Integrity check. Kept sections are diffed against the re-scrape, so a clause or a link next to an edit can't be silently lost.
Set it up
1. Install the plugin. In Claude Code:
/plugin marketplace add seranking/marketing-automation-plugins
/plugin install content-refresh@marketing-automation-plugins
In the Claude desktop app: Customize in the sidebar, then Personal plugin, + Add, Add marketplace, enter seranking/marketing-automation-plugins, and install content-refresh.
2. Connect SE Ranking. You need MCP access on a plan that includes the Data API. AI visibility checks also need SE Ranking's AI Search add-on. Without it, the audit skips that signal and says so in the report.
3. Connect Firecrawl. Any plan works. Occasional audits fit the free tier.
4. Optional: connect a Search Console MCP. The plugin looks for any connected MCP whose tools reference Google Search Console, checks that it is bound to the domain you audit, and skips every Search Console step silently if there isn't one. The README says no such connector is in the standard directory yet.
5. Optional: add brand-voice.md with voice notes and banned words to your working folder. Without it, drafts copy the voice of each page's untouched sections.
6. Run a small audit first. A five-page audit makes several dozen API calls and takes a few minutes, so start with two or three pages:
/plugin marketplace add seranking/marketing-automation-plugins
/plugin install content-refresh@marketing-automation-plugins
The second form is discovery mode. It finds pages that lost rankings over roughly the past year, weighs the size of the drop against the traffic still at stake, and works in one country database per run. A multi-market site needs one run per market.
7. Read audit-report.md and answer the approval question in chat. Then run /refresh-update or say "go ahead".
8. Review the drafts. Each one starts with an HTML comment holding the change summary. Delete it before publishing. Check any [NEEDS SOURCE] markers, then publish through your own CMS. The plugin never publishes anywhere.
9. Re-run the audit on the same URLs after 6 to 8 weeks. If Search Console was connected, the plan stored a baseline of clicks, impressions, CTR and position to compare against.
Everything from a run lands in content-refresh-runs/{date}-{domain}/:
audit-report.md
refresh-plan.json
research-{slug}.md
drafts/{slug}.mdOnly audit domains you own or manage. Every run scrapes two or three top-ranking competitor pages per target keyword, and the plugin isn't meant for pulling a third-party site at scale.
What the video has that the plugin doesn't
- Candidates. Internal setup (video): Notion inventory with performance and business metrics. Public content-refresh: Your URLs, or live SE Ranking data for a domain.
- Shortlist. Internal setup (video): Weighted scoring with slots for decay, AI visibility, product updates and business priorities. Public content-refresh: Size of the decline times traffic still at stake. Default 5 pages, maximum 10.
- Product and news signal. Internal setup (video): Slack channels read on every run. Public content-refresh: Not included. The context= argument takes free-text notes, so you can paste product changes there.
- Review. Internal setup (video): Slack digest and thread, go-ahead in Claude. Public content-refresh: Approval in chat.
- Unverifiable facts. Internal setup (video): Result marked "uncertain". Public content-refresh: Reverted or marked [NEEDS SOURCE].
- Output. Internal setup (video): Notion: change brief, preservation checklist, summary, article. Public content-refresh: Markdown files in the run folder.
- Re-check. Internal setup (video): About eight weeks later, written back to Notion. Public content-refresh: You re-run the audit after 6 to 8 weeks.
That comparison is also the list of what to build if you want the full version. A Notion or spreadsheet inventory replaces the live discovery step. A Slack or Notion page with product changes feeds context=. A shared thread replaces the chat approval for teams. The audit-to-plan-to-approval-to-draft contract in refresh-plan.json stays the same.
Add Search Console data
If you want the optional Search Console step, GSC MCP is a hosted, read-only server I run. It is a fork of Suganthan Mohanadasan's GSC MCP, which adds multi-property access, a remote server and per-user sign-in. It includes inspect_url, content_decay and cannibalization_check, which cover the indexing, decay and cannibalization checks the plugin asks a Search Console connector for. content_decay flags pages that decline across three consecutive 30-day periods. In Claude Code:
claude mcp add --transport http gsc https://gsc.k-o.pro/mcp
For the general Claude Code setup behind workflows like this one, see Claude for SEO: 3 Workflows I've Automated as a Practitioner.
