Scale SEO Content Updates Faster With Claude Code

SEO teams pour resources into creating new pages while existing content quietly loses rankings, clicks, and revenue. Updating those pages can recover lost ground, but rewriting too much can destroy the SEO equity they’ve already built.

Here’s a 14-step process for diagnosing content decay, making targeted updates, and measuring results , plus how we turned it into a scalable system with Claude Code.

Why existing pages deserve more attention

One of the brands I manage is a ground transportation marketplace with pages covering airports, resorts, and popular routes across multiple countries and languages. The methodology in this piece is the one we use there, which is why it’s the example throughout.

Every one of those pages decays over time. Not dramatically: no penalty, no algorithm update to blame. Just a slow drift. A ranking creeps down, impressions hold steady while clicks quietly fall, and an AI Overview eats the top of the search results. Google notices before your analytics dashboard does.

Take our Antalya Airport transfers page. Before we touched it, the 56-day diagnostic showed:

• 148,537 impressions.Buried, not invisible. Nothing was broken. It was just stale.New pages start at zero, so you can do whatever you want with a blank slate. That’s the fun, easy part of SEO to talk about.Updating a page that already ranks is a different job entirely, let alone a commercial, revenue-driving page. You’re working with a live asset:
• Internal links already pointing at it.I’ve watched teams “refresh” a decaying page by rewriting it top to bottom and losing every ranking it had. That’s not a refresh but a self-inflicted demotion.

The manual process

The full sequence, diagnostic to measurement.

Step 1: Read the 56-day GSC window

Every update starts with a 56-day window in Search Console, not 90 days or a full year. It’s wide enough to be reliable and narrow enough to stay within one season.

In this instance, the site is seasonal enough that a wider window just means averaging June against January and drawing the wrong conclusion from the blend. That locked window is also the baseline against which the eventual test gets measured.

Another reason we use 56 days is that the same time window is used when the content update is pushed live, and we set up the SEO test to track its impact. SEOTesting, the tool we use to set up SEO tests, offers four test periods: 2, 4, 6, or 8 weeks. Eight weeks equals 56 days, which is why we use that same time window as the baseline.

Inside the data, three things matter most:

• Top queries: These have to be preserved, whatever else changes.Step 2: Tag every sectionThis tagging discipline is really the whole game:
• Keep: Still ranks, still accurate. Don’t touch it.Steps 3-5: Read competitors, refresh keywords, rebuild personasThis is where it stops being generic. For Antalya, the query data turned up:
• A striking-distance opportunity: “antalya airport transfer” sitting at position 7, with real volume behind it.How the personas get builtThe personas come from a two-source process rather than a single dataset. The foundation is a sitewide taxonomy: a Google Search Console export covering the last 16 months, with every query across the site clustered into a master set of personas that holds across the whole portfolio, not just one page.For any specific update, that sitewide set is paired with SEOTesting’s Query Fan-Out tool and fed a seed term for the destination. It generates synthetic queries that people would plausibly ask within an LLM interface rather than type into a search box, and those are clustered into personas in the same way.The two datasets , one built from 16 months of real GSC behavior, one from synthetic fan-out queries for that specific destination , then get combined into the final, destination-specific set. For Antalya, that combination landed on four personas:
• The standard shuttle shopper.Steps 6-7: Refresh local knowledge, decide the angleWhat changes at an airport destination every 18 to 24 months:
• Terminal assignments.All of it gets checked against current sources, not assumed from the original brief.Then the angle. The original angle on a commercial page like this tends to start generic: something like “we make airport transfers easy.” That’s not an argument. It’s a brochure, and it said nothing to the four different personas whose data just surfaced.Antalya’s new angle: Different travelers need different transfers, and the page should surface the right answer based on who’s actually looking, instead of presenting every option to everyone and hoping they self-sort.Step 8: Write the delta briefNot a brief for the whole page: a delta brief covering only what changes. Each section gets one of the four labels from Step 2, explicitly, with a reason attached. It runs roughly 1,500 words for a page this size and reads more like an engineering change request than a writer’s brief, which is the right tone for the work.Step 9: Write the deltaOnly the sections tagged “fix” and “add” get written. That meant refreshed copy and keyword coverage across the “fix” list, plus one new “add” , a persona chooser, “Expert Airport Transfer Finder.”A visitor picks the option closest to their situation, and the module surfaces the vehicle recommendation, price range, and detail that matters to that persona.The component itself doesn’t add new information: all of it already existed somewhere on the page, spread across the vehicle explainers, the group-size guide, and the FAQ.It just gives each visitor a direct path to the part that’s already theirs, instead of asking them to scan the whole page to find it. It shipped as one part of the delta, not on its own, alongside the fix work above.Step 10: Fact-check everythingIncluding the “keep” sections. Staying doesn’t mean it’s still accurate, so every numeric claim (distances, prices, transit times, terminal assignments) gets reverified against current sources, including old content.Most “AI-refreshed” pages skip this part and update the surface text while leaving the underlying facts untouched.Steps 11-12: Audit images, preserve the SEO equityEvery image gets checked for three things:
• Still accurate.Anything that fails gets replaced.Meanwhile, the rule for everything else is preserved unless there’s a specific reason not to:
• The URL slug never changes.Step 13: Build the UI componentsWhen the brief calls for something visual rather than prose, we vibe-code it:
• Describe the behavior in natural language.The old workflow for a custom component was Figma mockup, design review, dev sprint, QA: call it two weeks, best-case scenario. This is closer to an hour for something of moderate complexity, which is the only reason a persona chooser is feasible per page across a portfolio this size rather than a rare, special-case build.Step 14: Measure the changeEvery update runs through SEOTesting, which we’ve connected to both Google Search Console and GA4. The GSC side gives us clicks, impressions, position, and CTR. The GA4 side gives us whatever actually matters commercially: the purchase event, in this case, or any other GA4 event worth tracking.The same locked window and control-versus-test structure are used on both sides simultaneously, so a content update is judged by revenue and sales, not just rankings.Here’s what the whole update produced on Antalya on the search side, measured against the 56-day baseline locked before a single word changed:| Metric | Control | Test | Change | |——–|———|——|——–| | Clicks/day | 39.55 | 49.00 | +23.88% | | Impressions/day | 2,652 | 2,744 | +3.44% | | Avg. position | 14.89 | 10.87 | ▲ improved | | CTR | 1.49% | 1.79% | +0.30pp | | Queries/day | 366 | 389 | +6.28% |Every single metric moved the right way: clicks up, impressions up, CTR up, position improved, and query coverage up. Most updates that move one number quietly cost you on another. This one didn’t, and it wasn’t down to any single piece of the delta.It’s what the diagnostic, the angle, the rewritten sections, and the new component produced together. That’s really the whole point of locking a baseline before touching anything: it’s the only way to know an update did something, rather than getting lucky with a publish date.

Turning it into a system through Claude Code

That whole process, done properly by hand, is about two focused days per page. hoppa runs thousands of pages across nine languages, and two days a page is fine math until you multiply it across a portfolio that size. Even at a conservative one update per page per year, the arithmetic doesn’t survive contact with reality.

The real cost isn’t the time, either. It’s the opportunity cost: every month a page like Antalya sits at position 14.89 instead of 10.87 is a month of impressions that never got the chance to convert.

So we mapped the 14 steps above into Claude skills and had Claude Code run the process instead of a person running it with AI help on the side. The judgment didn’t move to the machine. The enforcement of that judgment did.

The foundation is a dedicated Claude project, preloaded with:

• Our brand book.Every skill that touches content runs inside that project, so brand constraints are always in context instead of being re-explained on every run.The same 14 steps, mapped onto the skill chain that runs them at batch scale.Step 1 → hoppa-intelligencePulls the 56-day GSC window automatically and locks the baseline before anything else happens: the same four metrics, top queries, striking-distance queries, and zero-click queries a person would pull by hand.Step 2 → the Audit SkillRuns the keep/fix/remove/add tagging automatically, classifying every section against actual query performance.Steps 3-4 → the Competitor-Gap SkillPulls defended queries, gap-close queries, and new intents from Ahrefs, plus a SERP read on who’s outranking us and what ground they’ve taken.Steps 5-7 → Editorial IntelligencePersona revalidation and query fan-out gap detection, plus the local-knowledge refresh. This is where the hard gates sit: the update can’t proceed without:
• A validated persona set.Skip those and you get generic AI output, which is exactly why so much AI-assisted content reads the same regardless of who published it.Step 8 → the Delta-Brief SkillGenerates the brief in the same delta shape as Step 8 above (keep/fix/remove/add explicit) and won’t produce one without a defined angle attached.Step 9 → hoppa-editorialWrites only the “fix” and “add” sections, inside the same project, calibrated against gold-set tone benchmarks. If the new content’s voice drifts from the kept content’s, it refires until they match.Step 10 → hoppa-scientific-refinerFact-checks new and kept content. A failed check on a “keep” section automatically bumps it to “fix.” No human has to ask, “Is this still true?” first.Step 11 → the Image-AuditorRuns the same three checks automatically (accurate, on-brand, spec-compliant) and flags whatever needs replacing.Step 12 → seo-preservationLocks the URL slug, protects a meta title that’s earning CTR, and extends schema rather than replacing it, the same preserve-by-default rule as Step 12 above.Step 13 → the Component GeneratorTurns the brief’s spec for anything new (a persona chooser, a comparison table) into the actual working component, running the same describe-generate-iterate loop, just inside the skill rather than a person driving it by hand.Measurement (Step 14) isn’t a separate skill so much as the discipline that wraps around all of it. We still set up the tests manually. The baseline is locked in Step 1 before anything else runs, and every batch is read against that same baseline once it’s live.

Closing the loop: Deployment

Getting the content right was only ever half the job. The other half was getting it live, and until recently, that still meant a person copying finished sections into our CMS, checking that the formatting held, and hitting publish.

We’ve since closed that gap. Claude connects directly to our CMS, Strapi, through an MCP server we run for Strapi, and deployment itself now runs as its own step:

• Staging deployIf any check fails, the deploy halts and flags it rather than silently shipping something broken. When everything passes, it produces a single ready-to-publish report for a human to approve before it goes live.Content production and CMS deployment are now a single continuous pipeline, rather than two separate jobs with a person bridging them by hand.

What running this at scale actually taught us

Once the pipeline worked for one page, the obvious next question was how many it could run at once without compromising quality to the bare minimum.

We tested two content updates running in parallel. It works, technically: nothing errors out, and nothing breaks. But the quality drops on both.

The two runs share the same underlying agents, and pushing two batches through the same agents at the same time visibly softens the output on each: the diagnostics get shallower, the delta briefs get looser, and the writing needs more editing on review.

So we don’t run it that way, and we can’t without giving something up. One update runs at a time, start to finish, and the system works through a batch sequentially.

However, many URLs are on the list that week. It’s slower on paper. It’s also the difference between output we trust on the first read and output that needs a second pass to catch what got rushed. At this stage of the tooling, that trade isn’t close.

What the difference looks like on the page

Here’s the same underlying discipline applied to two other real pages, one still waiting in the queue and one through the full cycle:

Same template. Very different depth.

Not yet updated:

• Generic copyFully updated:
• Rich local detailNothing about that gap required a rewrite from scratch. It required the delta.

The results at portfolio scale

None of this matters if it only works on one page. We don’t call an update a win because it feels better. Every one of these runs as a proper test, with a 56-day baseline locked before a single change ships and measured against the same window after. That’s the difference between a measured update and a lucky publish.

Aggregate results across all 59 completed tests:

• Seven in 10 updated pages saw organic clicks increase.Across all 59 tests, normalized to comparable 56-day windows, this netted 2,284 additional organic clicks overall, all landing on a commercial transfer page, not a blog article.Organic purchases finished up 24.9% against baseline, and organic revenue was up 20.1%, both read straight off the GA4 side.That’s the argument for treating content updates as one of the highest-ROI line items on an SEO roadmap, rather than as maintenance work that happens only when there’s nothing more exciting left to do.

What actually transfers to your team

None of the specifics above is the point. Our prioritization weights, our persona schema, our tone benchmarks, and our gate thresholds won’t mean anything on your site, and they shouldn’t. Rebuild it all for your own domain.

What transfers is the shape of the system:

• A human sets the list and priorities and approves the output. Automation enforces judgment. It doesn’t replace it.Right now, revenue picks which pages we look at first, and the diagnostic tells us what’s wrong with them. That’s the correct order for a team defending high-value pages, but it’s reactive: decay has usually already cost something by the time revenue flags it. The signals exist earlier than that:
• CTR softening.The next version of this continuously monitors the portfolio and surfaces pages about to bleed, not just those already bleeding.Content updates on commercial pages can be some of the highest-ROI SEO work available, yet most teams still treat them as maintenance. Doing them properly, one page at a time, doesn’t scale.Ours didn’t either, until we stopped asking the model to write and started asking it to enforce judgment we’d already made, at whatever volume the queue actually needed.If you’re staring at a queue of decaying pages and wondering where to start, start with the diagnostic, not the rewrite. Everything else follows from that.None of this would have happened without the person who turned it from a manual playbook into a working Claude skill chain: Yvette Ramirez, our content strategist, who built the implementation and kept iterating on the gates and tone benchmarks until the automated version stopped needing a second pass.