90 Days of Headless Content: What Worked, What Didn't, What I'll Do Differently
Author: WebGoodPeople
Revised English edition, 11 October 2026. This edition keeps the practical framework from the original retrospective. Historical channel totals and uplift figures are omitted because their underlying measurements are not available in this edition.
A content program about headless commerce can produce attention without reaching the person who owns a buying decision. A retrospective should therefore examine who responds, what they ask and whether the material helps them evaluate a real store problem.
The purpose of a ninety-day review is to choose what to continue, change and stop. It is not to turn every popular post into evidence of commercial success.
Start with the audience and the channel
Write down the people you want to reach: the store owner, commerce lead, technical decision maker or internal implementation champion. Their questions differ. An engineer may want an API contract; a commercial owner may need the scope, price and risk of switching.
Choose a primary channel set and record why each channel belongs there. Personal and company accounts can serve different roles. Do not assume a platform works for your audience because it works for another team.
Separate long buyer materials from short posts that introduce them. A useful guide can answer detailed questions before a meeting; a short post can help someone discover that guide. Evaluate each against its role.
Track five signals without confusing them
| Signal | Question it helps answer | Limit |
|---|---|---|
| Impressions | Was the material seen? | Does not identify a buyer or prove attention |
| Engagement rate | Did viewers react, discuss or share? | Definitions and audiences vary across platforms |
| Clicks | Did people reach the linked material? | A click is not a qualified lead |
| Profile visits | Did people want to learn about the author? | Does not show the reason for interest |
| Relevant conversations | Did someone bring a real problem or buying question? | Needs a consistent qualitative classification |
Retain the URL, publication date, audience, format and measurement window for each item. Use tagged external links where appropriate. Do not compare a mature post with one published yesterday as if the exposure periods were equal.
Formats worth testing
An incident with a concrete lesson
A clear chronology can make an engineering issue understandable: what failed, how it was detected, what the team checked and how it recovered. Use actual artifacts and permission to discuss the incident. Remove customer identifiers when they are not needed.
The useful part is the mechanism and lesson, not an invented loss figure. An incident post should help a reader recognize a risk or ask a better operational question.
A calculation with visible assumptions
A cost model can help a technical champion discuss the decision internally. Show the inputs, formula, period and uncertainty. Product count alone does not determine revenue or the value of a conversion change.
Label an example as an example. Explain whether a percentage is relative growth or a change in percentage points, and avoid presenting hypothetical money as measured customer revenue.
Show the work
An anonymized query, API response, log schema or before-and-after field can make an explanation concrete. State where the data came from and which conclusion it supports. A fabricated dashboard image is not a substitute for evidence.
A useful artifact may attract a technical champion who can later explain the solution to the decision maker. Retain their actual question rather than inferring buying intent from a reaction.
Patterns that can mislead
Contrarian claims without a useful new argument
Disagreement can produce reactions while adding little information. Before publishing, ask whether the claim is specific, supported and helpful to the intended reader. A familiar “unpopular opinion” is not a strategy.
Repeated RU and EN posts to overlapping audiences
A person who follows both language streams may see the same argument twice. Test different topics or a wider interval between versions. On the website, useful localized versions remain valuable; feed repetition and multilingual SEO are different questions.
Generic strategy without practical detail
A broad recommendation to “choose a headless provider” is less useful than a guide that explains data ownership, migration boundaries, price and rollback. If a topic earns impressions but no relevant questions, inspect its depth and CTA before publishing more of it.
Engagement from the wrong audience
A discussion among engineers may look strong numerically yet contribute few store-owner conversations. This does not make the discussion worthless, but it must not be counted as proof of the commercial objective.
Review surprises as hypotheses
If a personal Telegram account produces more relevant conversations per visit, treat audience familiarity as a hypothesis to test. If a secondary publishing platform appears to send search traffic, check the source and landing-page attribution before assigning the effect.
Long articles may help readers evaluate a pilot, while short posts create discovery. Ask contacts which material they read, but keep self-reported attribution separate from analytics. Both can inform the review without being treated as complete evidence.
A practical ninety-day review
- Collect the same five signals weekly, with a consistent window and definition.
- Every month, inspect the strongest and weakest items for the intended audience.
- Describe the mechanism in one sentence: a useful artifact, a clear calculation, an unresolved buying question or an irrelevant audience.
- Choose what to repeat, revise, test and stop. Record why.
- After ninety days, compare qualified conversations and opportunities alongside traffic. Retain small-sample uncertainty.
Use this review to concentrate effort. It may mean fewer platforms, fewer broad topics and more detailed buyer materials. More published items are not automatically a better program.
Connect content to a real product decision
A commercial material should explain who the solution fits, what it requires, what it costs and what happens after a request. Link to the relevant product rather than sending every reader to a generic brief.
For catalog descriptions and SEO fields on 1C-Bitrix, explore Content Factory. For difficult product queries, review Site Search. For an existing store that needs a new storefront, see Frontbox.
This editorial framework concerns how a team evaluates its content. It does not make the historical retrospective a forecast of your store's traffic, conversion rate or revenue.
Read next
Articles on adjacent topics — from real projects.
Review AI product copy before updating your catalog
An editorial review process for AI product drafts, covering source material, unsupported claims, missing limitations, useful content, and checks after publication.
Blog · October 7, 2026Choose and define your first automation task
A practical framework for a first automation project, using an inquiry-to-CRM workflow to explain scope, rules, test scenarios, and ownership.
Blog · October 3, 2026Review product page content with a manual AI check
A practical way to review product copy using a manual AI exercise. Learn how to set boundaries, check evidence, record gaps, and avoid drawing conclusions about search or sales.
Newsletter
Headless migrations & AI pilots, unpacked
Every 2 weeks — real cases, numbers and architecture decisions. No marketing noise.