The most expensive thing my content automation ever did was work exactly as designed. Between April and May 2026, Google Search Console showed my site's indexed pages falling from roughly 7,000 to roughly 1,700 — a 75% collapse on a blog I'd spent years building. The pipeline wasn't broken. It was publishing faster than I was verifying, and Google noticed before I did. So here's my actual position on automating SEO and social media with Claude: automate the plumbing aggressively, automate the claims never. Everything below is the pipeline I run today on my own ~580-post site, including the parts that failed.
First, a correction. An earlier version of this post told a story about firing an SEO agency and replacing it with a hands-off, nine-platform publishing stack, complete with traffic numbers. I've deleted all of it, because I couldn't stand behind those numbers — and content I couldn't stand behind is precisely what got my site deindexed. What follows is only what I can show receipts for.
What I Automate, and What I Refuse To
After the crash I split every content task into two buckets.
Plumbing — automate it all: fetching and backing up database rows, applying edits, regenerating sitemaps, busting caches, checking links, tracking what's done and what isn't, drafting social copy from a finished article. This work is repetitive, verifiable, and Claude plus a few scripts does it better than I do.
Claims — never automate: anything that asserts a fact, a metric, a source, or an experience. Every number, quote, and citation gets human eyes before it ships. This is the bucket that, left unattended, produced posts citing sources that didn't exist — and it's why my index count fell off a cliff.
Most "automate your SEO with AI" advice ignores this split entirely. It pitches volume. I ran the volume experiment on a real domain, and Google's response wasn't a gentle ranking decline — it was wholesale removal from the index over about six weeks. Recovery, after I purged and fixed the offending content starting May 4, took roughly three months. That asymmetry — weeks to lose, months to regain — is the constraint your whole pipeline should be designed around.
The Rewrite Pipeline: 84 Posts, Zero Lost Work
The most useful automation I've built is not a content generator. It's a content repair system. When I needed to surgically rewrite 84 English posts — de-templating identical CTAs, fixing broken links, correcting facts that had drifted — I ran it as seven batches of twelve with Claude Code orchestrating. The architecture is boring on purpose:
1. A durable resume manifest. A single JSON file, REWRITE-STATUS.json, tracks every post as PENDING or DONE, with a small script to flip states. Sessions crash, terminals close, batches span days — the manifest means any new session picks up exactly where the last one stopped instead of re-checking 84 posts by hand. If your automation can't survive being killed mid-run, it isn't automation yet; it's a demo.
2. Backups before every write. Each post's full database row gets dumped to a JSON file before the rewrite touches it. I've never regretted a backup and I've twice been saved by one. Cost: milliseconds per post.
3. A guarded apply script. The script that writes to production refuses to touch any post ID outside the batch range it was given. When you're pointing automated writes at a live database, the blast radius of a bad loop should be twelve rows, not the whole table.
4. Hard verification, not vibes. A separate check script validates every rewrite before it applies: internal links resolve to slugs that actually exist, no leftover template phrases, word counts in range. The drafting model and the checking script disagree regularly — that disagreement is the system working. One recurring catch: the drafter kept emitting bare-slug and .md-suffixed links that render broken on the live site. A human skims right past those; the checker never does.
5. Cache-busting as a first-class step. Two things made rewrites look like they'd silently failed. My app caches rendered post content per post and locale, and the model observer didn't clear that key — so the database had the new text while the page served the old. And Cloudflare's edge caches pages for an hour, so even after clearing the app cache, the old version lingered. Now the pipeline clears application caches on every apply and treats the CDN hour as expected lag. If you automate content updates without automating cache invalidation, you will spend evenings debugging "failed" writes that succeeded.
One more scar for anyone scripting over SSH: ssh inside a while read loop silently eats the loop's stdin and processes exactly one item. ssh -n fixes it. I lost a real hour to that.
The deeper pattern behind these five pieces — recurring checks with durable state — is the same one I use for ongoing monitoring, which I covered in automating SEO checks with Claude Code routines.
Sitemap and Indexing: The Automation That Runs Itself
Rewriting content only matters if Google recrawls it. That part of my stack is fully automated and has been reliable enough that I forget it exists:
- Model observers invalidate the sitemap caches whenever a post, project, or page is created, updated, or deleted. No manual regeneration, ever.
- A scheduler rebuilds the sitemap every five minutes. Eight sitemaps cover posts, images, videos, and the site's other content types. Publish or update anything and the sitemap reflects it within minutes.
lastmodtracks real updates, not publish dates. This one is easy to get wrong. Early on, mylastmodvalues only reflected original publication, so Google had no signal that 84 posts had just materially changed. Fixinglastmodto track updates is one of the highest-leverage lines of code in the whole system — it's how a rewrite becomes a recrawl.- Tag hygiene, audited by Claude. An audit of my taxonomy found 62 groups of duplicate tags splitting the same topic across near-identical archive pages. Merging them consolidated thin pages into strong ones — my Claude Code tag page went from 6 posts to 198 after the merge. Fragmented archives are self-inflicted thin content, and they're exactly the kind of structural problem an LLM audit finds in minutes and a human puts off for a year.
The broader set of analysis tasks I hand to Claude — crawling my own sitemap, comparing coverage, flagging gaps — is in my Claude SEO toolkit guide.
The Social Media Part, Honestly
This is where I'll disappoint anyone shopping for a "post everywhere while you sleep" setup, because I ran that idea through the same filter as everything else and most of it didn't survive.
What Claude is genuinely good at: taking a finished, verified article and drafting platform-shaped derivatives — a thread that leads with the sharpest finding, a LinkedIn post that leads with the lesson, a short description for video. The register differences between platforms are real, and they're exactly the kind of transformation work LLMs excel at. I write these with a prompt that includes the article, the platform, and hard constraints on length and tone — the same five-slot structure I use in my prompt engineering guide.
What I keep manual: the send button. Distribution automation is trivially easy — every scheduling tool has an API — but trust is the constraint, not tooling. An error in a blog post is editable; an error broadcast to nine platforms is a screenshot. Draft automatically, review in one sitting, schedule deliberately. The drafting step is 80% of the time cost anyway, so automating it captures most of the win with none of the blast radius.
If you want to push further and have Claude produce social content at scale within a defined voice, the skill-based approach I documented in building a Claude SEO content writer skill is the right foundation — a skill file encodes your constraints once instead of re-prompting them forever.
What the Crash Taught Me About Scale
Three rules came out of watching my own index chart fall and slowly climb back. They're the design spec for everything above.
Verification has to scale with generation. If Claude can draft ten posts an hour but you can verify two, your pipeline's real capacity is two. The 84-post rewrite succeeded because the checking layer — link validation, fact spot-checks, backups, manifests — grew alongside the drafting layer. The crash happened because it hadn't.
Google's trust is a step function. My index count didn't decline in proportion to my worst content; it collapsed across the site, good pages included. Sitewide quality signals mean your weakest automated page taxes your strongest hand-written one.
Recovery is measured in months, so design for never needing it. Fixes deployed May 4; the index didn't look healthy until late July. Twelve weeks of reduced visibility bought by a few weeks of unverified publishing. I've done 1,500+ projects over 8+ years, and I can't think of another system where the failure-to-repair time ratio is that brutal.
If you're building your own version, start here: one manifest file, backups before writes, a link checker, and observer-driven sitemaps. That's a weekend of work, it's model-agnostic, and it'll still be the backbone when you swap in whatever model ships next year.
Where these pipelines fail in production is never the drafting — it's the missing verification layer, the lastmod that never moved, and the cache nobody thought to clear, and all three stay invisible until an index chart falls. I already paid for those lessons on my own properties, so when that's the problem sitting in front of you, get in touch.
