One of the big red herrings in marketing discourse is that AI has somehow made creativity and originality the future of marketing.
As my boss would say: “Bruh.”
It’s always been the thing and always will be.
What marketer out there thinks their company’s marketing should not be these things? Who’s saying, “I’m all in on AI slop and blending in”?
Please, I would love to meet them and buy them a beer.
Occasionally you’ll see Ramp do something like hire Kevin from The Office and stick him in NYC in a glass box, and you feel that twinge of “I want to do stuff like that.”
And then you remember Ramp has raised billions of dollars.
The time, talent, headspace, freedom, long-term thinking and budget required to be genuinely excellent and creative is severely underestimated. It’s easy to say it. It’s considerably harder to create the conditions to actually do it.
This is one of the reasons I have been, and continue to be, bullish about AI. It’s also why I’m tired of the false narrative that pits marketers into two camps: AI spreadsheet monkeys and frustrated creatives. This is both unhelpful and annoying.
Maybe I’m naive, but I still believe that reducing grunt work will give people more time, energy and freedom to do things that truly stand out.
Of course, there’s no guarantee that companies will reinvest those efficiencies in creativity rather than demanding more-of-the-same output. But that’s an organisational choice and not an inherent limitation of AI.
And yeah, we should absolutely question why so much bullshit work exists in the first place. But internal coordination, updates, moving things between systems, data entry, etc. aren’t going to disappear because you’ve been watching Mad Men shorts on YouTube.
I don’t want AI to help me make more mediocre marketing. I want it to help me make fewer compromises about the marketing I actually want to make.
And I suspect I’m not alone.
What does this have to do with refreshing blogs?
Most companies have a blog. And most blogs become outdated as quickly as an opened jar of pesto in your fridge.
A product changes. A regulation comes into force. A competitor launches something new. That lovingly crafted guide to the best software is now recommending a product that was acquired and sunset.
In the past, there were two options:
Screw it. Who cares if that blog says a new regulation is coming on a particular date and that date has now passed?
Manually rewrite everything. Spend time trawling through old posts, figuring out what’s changed, checking facts, updating screenshots and rewriting paragraphs.
The problem with option one is that AI search engines can retrieve more recent information, compare sources and potentially surface someone else’s answer instead of yours. You want these engines to see you as the authoritative source.
The problem with option two is that if I’m a marketing leader with a decidedly non-Ramp-sized budget, I don’t want my small team spending their days updating old blog posts while other companies are locking beloved sitcom actors in glass boxes and generating millions of impressions.
Which brings us to option three: let AI do it.
So here’s how to automate it
To know what blogs are worth refreshing you need to first do an inventory of them. I wrote about how to do this here with a topic cluster workflow. You’ll also want a basic version of a truth layer for your brand. You can find out how to do that here.
As always you can find the entire blog refresh workflow in the repo for this newsletter (this is a skinny version of it you’ll need to adapt). The architecture is as follows:
Audit: what the SERP answers, what the page misses, what’s now wrong
Detect: which era of the blog is this page from? which fingerprints must go?
Draft: against the voice guide
Lint: until errors are zero with each surviving warning getting a written reason
Verify: every claim mapped to a source, gaps flagged for a human
1. Audit
The 2021 version of this (the skyscraper method) was pretty straightforward: look at the top ten results, see what they cover, find the gaps.
That worked reasonably well when you were trying to rank a page for a particular query. But AI search changes the equation. An AI engine can break a question into smaller questions, search for answers to each, and piece together a response from different sources.
So if my page only answers the main question, I risk losing out to pages that answer all the questions around it.
The audit needs to account for that. It builds out the full set of related questions, or fan-out queries, using five sources:
Systematic expansion. Start with the topic and work through every angle. What is it? How much does it cost? Is it secure? Is it better than the alternative? Does it work with X? How do you set it up? Who is it for? Does the answer change by country or over time?
Keyword data. Where you have it, use search volumes to understand which questions people are actually asking.
People Also Ask. Particularly useful for the comparison and judgment questions.
Reddit. A script pulls together questions people are asking about the topic. This is where you find the language and questions that don’t always show up in keyword tools.
Competitor FAQs. What questions are other companies answering that we aren’t?
All of that gets deduplicated into a simple coverage table. One row per question or topic, marked as covered, partially covered, or missing.
The audit also reads the live page claim by claim, checks it against up-to-date sources, and flags anything that’s wrong, contradictory, outdated, or can’t be backed up. Each finding gets a severity so I see what needs attention first.
The whole thing gets saved as a separate file alongside the draft, and becomes the brief for the refresh.
Every missing question becomes a potential heading or FAQ. Every accuracy issue gets carried into the verification report at step five.
2. Detect
If you’ve had a blog for some time, chances are you’ve gone through different eras. (Yes, your blog is like The Beatles.)
Refreshing a relatively new post means maintaining the current house style. Refreshing an old one means migrating it out of a deprecated one.
This step simply assesses the work to be done on this front and may or may not be necessary depending on how long your company’s blog has been around.
3. Draft
I worked with Claude to read a markdown version of the current blog (598 English posts, the whole corpus) and had it create very granular guidelines. Here are a sample of some of the things it found:
The intro follows a pretty consistent pattern. A hook, a turn, and a promise of what’s coming, spread across 3–6 short paragraphs. About 70% of recent posts follow it.
We talk directly to the reader. “You” or “your” appears within the first three paragraphs, and roughly a third of the time, it’s in the very first sentence.
We use contractions. About 15 per 1,000 words. We write “it’s” and “don’t” rather than sounding like we’re drafting a legal document.
We keep paragraphs short. The opening paragraph averages around 40 words. Most paragraphs are just 1–3 sentences, and almost never more than four.
And then there are other little things nobody would think to put in a style guide. Like how often we use a fragment-question to move an argument along. “The problem?” “The catch?” “So what changed?” It shows up one to three times per post.
Noting frequencies stops the guide being a straitjacket. “About 70% of posts” tells an LLM this is the default and that nothing is an absolute rule.
This could be its own post because, if I may say so, I’m pleasantly surprised by how the redrafted copy sounds.
4. Lint
A script reads the draft and looks for two things:
Errors. The stuff we know is wrong. UK spelling when our house style is US English. An emoji. A link that just says “here”. A heading wrapped in bold. “E-mail” instead of “email”. “20 percent” instead of “20%”. These are hard fails. The draft doesn’t move forward until they’re fixed.
Warnings. The stuff that deserves a second look, but isn’t necessarily a reason to stop publishing. A 3,358-word explainer when our usual range is 1,400–2,600. The primary keyword appearing in just one H2 when our house norm is 3–5. These get flagged for a human to review, not blindly enforced.
The key distinction is some things need fixing and others need thinking about.
5. Verify
It then creates a verification report and saves it alongside the draft. The idea is simple: I should be able to check any claim in under a minute without having to do the research all over again.
Nothing fancy. Just a table with every factual claim, where it appears in the draft, and where the information came from. That might be our own research, an existing page, an external source, or something live that needs a human to double-check it.
It also tells me what’s missing. What had to be cut or softened because we couldn’t back it up? Which stats are getting a bit old? Is there anything about pricing or competitors that needs someone to take a proper look?
That also means if there’s no verification file, there’s no publishing.
Turning this into a system
The final step is a human review where I read through the post and adjust anything that is funky.
I have built a tool that keeps track of what’s been shipped and the results. So far it’s been promising for the 22+ articles I’ve updated.
The next iteration is to make this more proactive. Rather than waiting for traffic to decline or someone to notice an outdated claim, I want the system to identify when something materially changes and flag the articles that need attention.
As I’ve argued before, the real magic happens when you automate systems and not just tasks. 😉