This is a Build Log case study. Build Log is my email on building go-to-market systems, written from my work as a freelance product marketing and growth consultant. Each issue collects one to three case studies like this one, and every case study ships with its working code in an open GitHub repo, linked at the end.
Before getting into the workflow itself, I’d like to use this first case study to introduce myself and what I’m looking to do here. My name is Nico, and I’m a product marketing consultant with 7+ years of marketing experience across industries.
Most of my work connects two levels of product marketing.
- Strategy: positioning, messaging, the calls about where to compete.
- Application: the content, research, and design where that strategy has to show up.
This case study is a full system: the content pipeline I run at Rock. The full blog is managed by one operator (me) and can produce SEO/AEO content that ranks with some supervision.
Rock’s blog & my history with it
Rock is an all-in-one chat + tasks platform that was started over 7+ years ago. Currently it’s still active, although it’s just a small team managing the day-to-day operations.
Running Rock’s blog was one of my first responsibilities when I joined back in 2020. An SEO agency we worked with taught me how it all worked, from keyword research to what separates a good brief from a useless one.
Back then the workflow was manual and expensive. I researched the keywords, wrote the brief myself, and handed it to freelancers. Sometimes I wrote the articles too, which is fine until you need volume.
Rejoining Rock as a freelancer now, my first thought was that there had to be a better way to run this. My plan wasn’t to bulk produce 200 articles in one afternoon.
I wanted to produce articles of substance/value that can be managed by one operator in a way that still allows you to keep up enough of a cadence to compete with bigger players.
Why managing the blog made sense from a PMM perspective
Before the mechanics, the reasoning. Putting real work into Rock’s blog was a deliberate bet, and it made sense because three things lined up at the same time.
The category is commoditized and the content map is known
Rock is a chat-plus-task-management tool. That is a well-defined product category with well-established search intent. People search for comparisons, alternatives, methodologies, and feature explanations.
There is no need to invent demand or write a category-defining manifesto. The articles that earn rank here are the ones that match known intent with better depth, better structure, and a real point of view.
The competitive timing is good
Rock's domain already had years of accumulated authority and a stale archive of almost 150 blogs that were already published over the years. Existing pages were already ranking in the 30s to 60s; a refresh and a tighter link mesh can help bring them to the top 10–20 if done correctly.
Bigger players were visibly slowing content production. Some are spooked by AI-content penalties, some are cutting budgets, some hit the search ceiling without a system to adapt. A small operator with a working pipeline can move faster than a large team with a Google Doc and a quarterly planning cycle.
The blog is a foundation, not a unique destination
Organic traffic is the easy outcome to measure, but it is not the only thing the system produces. A dense content library gives paid campaigns more landing surface, gives conversion testing more pages to work with, and makes partnership conversations easier.
The content engine becomes the substrate everything else compounds on: PPC, lifecycle messaging, sales enablement. Organic traffic from the blog is only a small part of its value; it also gives me the foundation to run dozens of GTM and lifecycle experiments on top.
What the pipeline outputs
Here’s the anatomy of a finished article — a 1,800 to 3,500 word piece, depending on topic depth. Hover any feature on the right (or any block in the preview) to see how they map together.
Tap any numbered block above to see what it does.
- 01Thumbnail
Pulled from a library of 500+ images or designed on the spot by Claude as a vector.
- 02Headline + lede
Tight, search-intent-matched title with a one-paragraph lede beneath.
- 03Quick Answer block
Plain prose right after the intro — the paragraph search engines and AI Overviews pull from.
- 04Table of contents
An anchored TOC at the top with jump links to every section.
- 05Body + inline images
A figure every 400–500 words. Thumbnail and first body figure deliberately different.
- 06Inbound linking
Contextual internal links dropped inside sentences that genuinely need the related concept.
- 07Outbound linking
No-follow where needed, general links to top research and authoritative pages.
- 08Interactive widgets
A draggable kanban, a meeting-cost calculator — tied to the article topic.
- 09Tables
Comparison tables in head-to-head articles. Explainer tables for easier scanning.
- 10Pitfalls / Benefits
Friendlier visual designs for the do/don't sections.
- 11FAQ section
At the bottom with schema markup so Google and AI Overviews can pull from it cleanly.
The whole thing pushes directly from the terminal into Webflow. No copy-paste into the Designer, no manual asset uploads. The article comes out ready for a post-publish check and a final eye-check before it goes live.
Here’s the kanban widget the Rock article above ships, ported verbatim from the production source. Drag cards between columns, push past the WIP limit, drop one into Done, or add your own card to the backlog.
Try a Kanban board
Drag cards between columns. Watch In Progress turn red when you exceed its WIP limit of 3.
How the system works
The pipeline has four layers: brief, research, writing, review. Here is what each one does, and the decision inside it that actually matters.
The brief decides about 80% of an article’s quality
A generic brief produces a generic article. As mentioned in the intro, the brief is a big make or break moment for whatever you’re producing, so it should definitely have a human review gate/tweaks before you start any writing.
I typically spin up 4 agents in parallel to help compose the brief:
- Google Search Console Agent: Check what keywords we’re already ranking for, understand the topical cluster and find gaps for new articles.
- Google Analytics Agent: How are existing pages doing, where could the cluster gain more impressions, pages that have been dropping steadily that might need a refresh.
- SERP agent: a live check of the top 10 search results on a specific keyword: what every competitor covers and what nobody does.
- Editorial agent: Internal branding/positioning configuration that holds the editorial rules as data rather than vibes, so that the new angles in content also align with the product storyline.
The output is a single markdown file with the title, keywords, search intent, an outline with the purpose of each section, widget and image guidance, and candidate quotes. It is about 30 minutes of work, half of that human review.
I have found that the biggest differentiation lives in that search-results check. The brief does not only tell Claude what to write. It tells it what has already been said, and what has not. It then mirrors that to my positioning and product marketing intelligence to find a relevant angle for Rock.
Drafting is the automated part, and that is the point
Once the brief exists, the rules for writing a good article are encoded and the inputs are clean, so drafting is mechanical.
Claude writes a section at a time with the brief in context. One naming detail is worth flagging here. I call the draft-time check “lint”, not “review”. The word is borrowed from code linters because that is the right mental model: a pass-or-fail gate that runs on every output, not a soft suggestion to revisit later.
There is a practical reason too. Claude Code consistently skips steps labelled “review” and treats anything labelled “lint” as a hard gate. Small word change, real behavioral difference.
Two additional parts of the writing layer are worth calling out:
- Internal linking: Every SEO guide says to link internally and almost nobody does it well at scale, because by hand it is brutal: 150 articles in the archive, a new one to wire in, two hours of reading old posts to find the right anchor sentences. My workflow keeps a link library of every article and its anchor candidates, and an LLM scores each possible link for contextual fit, so forced links get rejected and only the ones that help the reader get proposed and inserted.
- Images: My asset library has more than 500 images. I have categorized every image with meta-data, and the blog writer picks images relevant for the copy and directly inserts them.
The review layer checks the live page, not the draft
After an article goes live, the system fetches the rendered article that Webflow actually published and runs the full check against it. This reduces the manual effort to fix simple things (broken text or images) after the article is already published.
The check has five passes:
- Editorial: Does the full article read nicely, no weird grammar/spelling?
- SEO: Does the article follow popular search engine optimization rules?
- GEO: Do I make it easy and relevant for LLMs to mention my content?
- Ideal customer profile: Is this appealing to the target audience I have defined within the PMM strategy?
- Render: Did anything break upon uploading the content?
Most articles pass clean. Whenever it catches a mistake, I investigate why/how that happened and implement a new rule for the system. The more I produce, the better the system gets as I solve edge cases and bugs in the pipeline.
I’m deliberately leaving out the technical mechanics, jargon, blockers, API insights and specs out of this article, you can dive deeper into that in the GitHub repo.
The results, honest
Across roughly two months the pipeline shipped about 200 articles, run by one operator part-time (me). That number is uncomfortable to publish in the era of AI-content discourse, so it needs context.
Most of it was not net-new. Rock had about 150 existing posts, most of them stale, broken, or out of date. The bulk of the work was a refresh pass plus a cluster cleanup: rewriting outdated articles, fixing dead links, rebuilding the internal mesh, filling cluster gaps where one article needed three siblings to rank. The smaller slice was net-new pieces targeting gaps Google had no good answer for.
Volume has dropped since. Google ranks at its own pace, the search results have a ceiling on how many pages from one domain they will surface for similar queries, and writing past that point is throwing energy at a slot that does not exist.
The cadence now sits closer to 5 to 10 articles per week at the most, often less, focused on filling specific gaps and refreshing high-impression pages that are softening.
Worth saying directly: if your domain has no existing rank or trust, blasting out 200 articles is the worst possible move. Google will not index them, the AI engines will not cite them, and you have burned weeks on filler.
The pipeline made sense at Rock because the domain already had authority and a stale archive, so the work was unlocking traffic that was one refresh away from showing up. On a brand-new site the right play is the opposite: 10 to 15 articles, deeply researched, written for one narrow cluster, then ride the slow ramp.
Now the actual numbers. Everyone in SEO is feeling the AI search shift and I am no exception. Here is the honest version, not the cherry-picked one.
Where the pipeline brought value to Rock
Search visibility is up.
- Blog impressions hit 859,790 in the last 28 days, up 79% on the prior period.
- Average position improved from 12.8 to 10.8. The blog’s typical result has crossed onto page one.
The ranking footprint expanded.
- Blog pages earning impressions nearly tripled, from 126 to 350.
- 12,058 query-and-page rankings sit in the top 10, 2,413 of them in the top 3.
AI engines are starting to send traffic.
- Referrals from ChatGPT, Gemini, Perplexity, and Claude grew from 40 to 111 sessions, up 177%.
- Still small in absolute terms, and it engages only slightly better than organic search (48% vs 44%).
Where I’m not yet seeing the numbers I’d like to see
Blog clicks dropped about 22% in the same window. Click-through rate fell from 0.65% to 0.28%, more than halved. AI Overviews are eating click intent: I get the impression, Google answers the query inline, the reader never clicks through. It is the industry pattern right now and I am inside it, not above it.
The honest read on clicks: most blogs are losing click volume right now for the same reason, and Rock is not exempt. What the pipeline does is offset some of that drop with more refreshes and more pages ranking. If a slot gets eaten by an AI Overview, the system finds the next slot to fill. Without it, the click number would be in worse shape than it already is. The aim is not to outrun the industry shift. It is to keep enough of the foundation working that the rest of the GTM stack still has something to build on.
What is in the open-source repo
The whole pipeline lives at github.com/nicolaas-spijker/build-log, with the Rock-specific pieces stripped out. The content pipeline is the 01-content-pipeline folder, and each new workflow adds its own numbered folder.
What you can run today:
- Link library builder: scrapes a blog and generates SEO anchor candidates for every article.
- Inbound link suggester: takes a draft and the link library, then proposes contextual internal links scored for fit, so forced links get rejected.
What is there as a documented skeleton, not yet runnable:
- The GSC, GA4, and SERP data pulls, the image picker, the Webflow push helper, and the post-publish audit. Each ships as a stub with a TODO header and the design written out. The working versions still have too much Rock-specific schema to share cleanly, so each new case study promotes one stub to be fully built, with a writeup on why it works the way it does.
Also included: the brief template, three example widget files (table, pitfalls, table of contents), and a CLAUDE.md operating manual covering the conventions, the Webflow gotchas, and the five-pass check, so an agent or a person can pick the repo up without context from me.
What is deliberately not in it: API keys, tokens, the Rock-specific CMS schema, customer data, and Rock’s image library. Everything runs off environment variables, and .env.example lists every one. License is MIT.