Larkspur Ledger

News: our 2026 benchmark data is free to download

2026-10-31T00:00:00Z

From today, anyone can download sample benchmark data from our 2026 content benchmark, free and under an open licence. The file sits on a new page with a data dictionary, our method and a note on how to cite it.

What we released

The new download page holds one spreadsheet file in the CSV format, which any spreadsheet app opens. Each row is one blog. Each column is one habit we counted: whether posts carry an author name, how many descriptions were left blank, whether anything was updated in the past year, and whether numbers link to a source.

The page also explains every column in plain words, so you can check a figure before you quote it.

Why we opened the benchmark data

We publish numbers in almost every post. Readers who want to check them should not have to take our word for it. Opening the benchmark data lets you rebuild our charts, test a different cut, or tell us where we got something wrong.

It also follows our own advice. Our complete guide to content strategy argues that original data is one of the few things a small team can publish that nobody else has.

How you may use it

The file is shared under the Creative Commons Attribution 4.0 licence. You may copy it, change it and use it in your own work, for any purpose, as long as you name Larkspur Ledger and link to the data page.

What comes next

We will add the 2027 rows next autumn, in the same columns, so the two years line up. If a column would help your own planning, write to us and say what you would do with it.

For the findings themselves, start with the 2026 content benchmark, which walks through each habit and what it means for a small team.

A first topic cluster, step 3: link the cluster

2026-10-31T00:00:00Z

You picked a subject in step 1 and planned the posts in step 2. The posts are written. Now the links turn a pile of posts into one topic cluster that readers and search engines can follow.

The links every post in a topic cluster needs

Each short post links to the Pillar post near the top, in a sentence that says why the reader might want the whole picture. The main post links to every short post from the section that covers its part.

Then link the short posts to each other where one leads to the next. A post on finding a fault should point to the post on fixing it. Do not link everything to everything: each link should be one a reader would click.

Words that say where a link goes

The words of a link tell a reader what they will find. "Read more" says nothing. "How to bleed a radiator" says exactly what is on the other side. Use the words of the post's question where they fit the sentence.

Vary the words a little across posts. Twenty links with the very same words look made for machines, not for people.

Check the links before you publish

Read each post as a stranger would. Click every link. Each one should work, land on the right post and make sense where it sits.

Khalid checks the rest for you: it warns when a post in the cluster does not link to its main post, when a post has no links in, and when two links use the same words for different pages. The Ahrefs guide to internal links explains why these checks matter.

What comes after

A cluster is never quite done. Each quarter, look at which short posts readers find and which they skip. Refresh the weak ones with our content refresh playbook, and add a new short post when readers ask a question the cluster does not answer yet.

AI referral traffic: finding AI visits in analytics

2026-10-30T00:00:00Z

AI referral traffic is the set of visits that reach your blog when a reader clicks a link inside an AI assistant's answer. Some of them show up in your analytics with a clear source. Others arrive with no source at all and hide among your direct visits. This post shows how to find the ones you can see, group them, and read them without fooling yourself.

It sits in our AI search guide, which explains how these tools choose what to cite in the first place.

Where AI referral traffic comes from

When you click a link on one site, your browser tells the next site where you came from. That note is the referrer, and analytics tools read it to name the source of a visit. The Referer header on MDN explains how it works and when a browser leaves it out.

Several AI assistants send a referrer when a reader clicks a cited link in the browser. The domains we see in our own reports include:

chatgpt.com for ChatGPT
perplexity.ai for Perplexity
gemini.google.com for Gemini
copilot.microsoft.com for Microsoft Copilot
claude.ai for Claude

Some assistants also add a tracking tag to the link, such as utm_source=chatgpt.com. Your analytics will then show that value as the source even if the referrer is missing.

Why some AI visits look like direct traffic

Not every click carries a referrer. A link opened from a phone app, a link copied into a new tab, or a strict privacy setting can all strip it. Those visits arrive with no source, and analytics files them as direct.

So the AI referral traffic you can see is a floor, not a total. The real number is higher by an amount you cannot measure. Treat any count as "at least this many", and watch the trend over months rather than the size of one month.

What Search Console shows for Google's AI features

Google's AI Overviews and AI Mode link to pages too. Clicks from them come from Google itself, so analytics files them as organic search, not as AI referrals.

In Search Console, Google counts those clicks and impressions in the Performance report for web search, together with the other results. Google's page on AI features and your website describes this. At the time of writing the report has no filter that splits them out, so treat any tool that claims to show them apart with care. Our Search Console setup guide covers the report itself, and our study of which pages AI tools cite shows what earns those links.

Build an AI channel in your analytics

To track AI referral traffic over time, give it a home. Most analytics tools let you define your own channel, or at least a saved segment, from a rule on the source of a visit. The rule below matches the domains listed earlier. It is a regular expression, a short pattern that matches many values at once.

.*(chatgpt\.com|openai\.com|perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai).*

The leading and trailing .* let the pattern match whether your tool checks the whole value or only part of it.

Find where channels are defined

In Google Analytics this is the channel groups setting in the admin area. In other tools look for channels, sources or segments. The Analytics Help Centre has the current steps for Google's tool.
Copy the default group

Work on a copy, so the original reports stay as they were. Name the copy something plain, such as "Channels with AI".
Add a channel named AI assistants

Set its rule to "source matches regex" and paste the pattern above.
Move it above referral

Channel rules run in order, and the first match wins. If the AI channel sits below the referral channel, those visits are counted as referrals before your rule sees them.
Check it against raw sources

Open a report of sources for the last month. Every AI domain you can see there should now fall into the new channel.

What to compare once you can see them

A count of AI referral traffic on its own tells you little. The useful questions are about which pages and which readers.

Compare	Why it helps
Landing pages	Shows which posts the assistants cite most
Engaged visits	Shows whether readers stay or bounce straight back
Sign-ups and enquiries	Shows whether the visits are worth anything to you
The same pages from organic search	Shows whether AI readers behave differently from searchers

Example data for a small blog, not real figures. Notice that one source sends most of the visits, so a change in that one assistant moves the whole line.

In our own reports, the landing pages tell the clearest story. The posts that draw the most AI referral traffic are the ones with a plain answer under each question heading. If you want more of them, our guide to writing answer capsules is the place to start. To judge whether those visits pay their way, see our post on what content is worth to a business.

The limits of what you can measure

Keep three limits in mind when you report on AI referral traffic.

The count is a floor. Visits with no referrer are lost to direct.
Google's AI features are mixed in. They sit inside organic search and inside web search in Search Console.
Sources change. Domains move, apps change how they open links, and new tools arrive.

None of this makes the numbers useless. It makes them a trend to watch, not a total to report as fact.

Search traffic in 2026: what our client charts show

2026-10-30T00:00:00Z

Every month we send each client the same three charts about their search traffic. They answer the questions owners ask most: is the blog growing, which pages bring readers in, and how much of it now comes from AI search. This post shows the three charts for a typical client in 2026 and how to read them.

The numbers below are from one anonymised client, a software company with a blog of about two hundred posts, and come from its own Search Console and analytics, read on 31 October 2026.

Search traffic month by month

The first chart is the one owners look at first: visits from search engines each month, split into Google and every other engine. The numbers sit in a CSV file next to this post, so we update the file and the chart redraws itself when the site is built.

Visits from search in 2026, in thousands CSV

Visits from search in 2026, in thousands
Month	Google	Other engines
Jan	18.2k	2.1k
Feb	19.0k	2.2k
Mar	21.4k	2.4k
Apr	22.9k	2.6k
May	24.1k	2.8k
Jun	25.3k	2.9k
Jul	24.6k	2.9k
Aug	22.8k	2.7k
Sep	26.9k	3.1k
Oct	29.4k	3.4k

Search traffic grew steadily after a slow start. The dip in August is the summer, not a problem: it happens in the same weeks every year. Read a chart like this one against the same months last year, never against last month alone.

Which pages bring readers in

The second chart lists the pages that brought the most visits from search in October 2026. Long guides and comparisons lead, and the home page is not even in the top five.

Visits from search by page in October 2026, in thousands

Visits from search by page in October 2026, in thousands
Page	Visits
Pricing guide	4.2k
Comparison with rivals	3.6k
Setup checklist	2.9k
Glossary of terms	1.8k
Home page	1.1k

If most of your search traffic lands on a few guides, give them the most care: update them first, link to them from new posts and keep their titles sharp. Our playbook for posts that slipped shows how.

How much comes from AI search

The third chart is new this year. It shows the share of visits that came from AI search tools, such as answers that cite the blog, in each quarter of 2026 beside the same quarter of 2025. To earn more of those visits, read our guide to writing for AI search.

Share of visits from AI search by quarter, 2025 and 2026

Share of visits from AI search by quarter, 2025 and 2026
Quarter	2025	2026
Q1	0.6%	2.1%
Q2	0.9%	3.4%
Q3	1.4%	4.8%
Q4	2.0%	6.5%

The share of search traffic from AI tools is still small, but it tripled in a year. Pages that state a fact plainly and show its source get quoted most, as our post on how AI search picks which pages to quote explains.

Where our clients are

Most of the blogs in this report belong to companies near our Bristol office. The map is a live one: drag it, zoom in and out, it works right here in the post.

A map of Bristol, where most of the companies in this report are

Build these charts for your own blog

You do not need a dashboard tool to chart your search traffic. Export the months from your analytics as a CSV file, put it next to the post and name it in the chart. Our own planning tool, Larkspur Planner, makes the same three charts from your Search Console data and keeps the file up to date for you.

A first topic cluster, step 2: plan the posts

2026-10-30T00:00:00Z

In step 1 you picked one subject and listed six or seven parts of it. Now turn that list into a topic cluster your team can write in a month or two.

One main post at the centre of the topic cluster

Every cluster has one Pillar post: a long post that covers the whole subject at a glance. It answers the big question in a few lines, then gives each part a short section that ends with a link to that part's own post.

Write it last, not first. By the time the short posts are done, you will know the subject far better, and the main post will be sharper for it.

One short post per part

Each part gets a post of its own that answers one question well. Keep each to one job. A post that tries to answer three questions answers none of them clearly.

Give each short post a brief before anyone writes a word: the question, the reader, the one thing they should do after reading, and the posts it links to. Our content brief template holds all of this on one page.

Put it on the calendar

A cluster of seven posts is two months of work for a small team. Spread it out: one short post a week, with the main post at the end. Leave a gap every few weeks for edits and late facts, as our content calendar guide explains.

Write the plan down in one place

Keep the plan in one sheet: the subject line you wrote first, each post's question, its writer, its due date and its links. When someone asks what the cluster is for, the sheet answers.

The search engine guides from Moz say the same in their own words: plan around what searchers need, not around single words.

Next, step 3 links the cluster, so every post leads readers to the next one.

A first topic cluster, step 1: pick one subject

2026-10-29T00:00:00Z

A topic cluster is a group of posts on one subject. One long post covers the whole subject, and shorter posts each take one part of it. They all link to each other. This series builds a first cluster in three steps, and this is step one: pick the subject.

Find a topic cluster in what readers ask

Look at the questions your readers send you, the calls your team takes and the words people type into your site search. Write each one down as the reader said it. After a week you will have a list of thirty or forty questions.

Now group them. Most lists fall into four or five groups, and one group is nearly always bigger than the rest. That group is your first subject. It is what people already want from you.

Check that you can cover it well

A cluster needs depth. Before you commit, list six or seven parts of the subject that each deserve a short post of their own. If you cannot find six, the subject is too small. If you find twenty, it is too big: split it and pick one half.

Then check who will write. Each part needs someone who knows it from real work. A cluster written from other blogs adds nothing new, and readers notice.

Write the subject in one line

End this step with one sentence that names the subject and the reader, such as "boiler faults, for home owners who want them fixed today". Keep it on the wall. Every post in the cluster should serve that line.

Google's own guide to creating helpful content asks the same thing: who is this for, and does it help them?

Next, in step 2, plan the posts, you turn the list of parts into a plan with one Pillar post at its centre. Then step 3 links the cluster so each post leads to the next.

How AI search chooses the pages it quotes

2026-10-27T00:00:00Z

AI search tools answer a question in a few sentences and name a handful of pages as their sources. Being one of those sources is the new first place. This post explains what those tools look for when they choose a page, and how to write posts they can quote with confidence.

None of this replaces good writing for people. The pages AI search quotes are, almost without exception, pages a human reader would also find clear. For the whole plan, from crawler access to measuring visits, see our complete guide to optimising content.

How does AI search pick a source?

An AI search tool first runs an ordinary search for the question, then reads the best pages it finds. It looks for short passages that answer the question directly and agree with other good sources. The pages it names are the ones whose passages it used, so clear, quotable answers win.

What makes a passage easy to quote?

A quotable passage answers one question completely in a few sentences, without needing the paragraphs around it. It names the subject instead of saying "this" or "it", gives the number with its source, and stops. We call this pattern an answer capsule, and we put one under every question heading.

Does ranking in ordinary search still matter?

Yes. Most AI search tools start from the pages a normal search engine already ranks, so a page nobody can find is a page nobody quotes. Good ordinary rankings put your post on the reading list. Clear passages, real sources and a named author then decide whether the tool actually cites it.

What we saw in our own numbers

We looked at the questions our readers ask most and checked which pages the main AI search tools named as sources. The pattern was clear: the pages that were cited answered in the first paragraph under a heading, and most of them named a source for every number.

The pages that were passed over had the same facts, but buried. They opened with a story, saved the answer for the end, or spread it across a long paragraph that also covered two other points.

The tools are not looking for the longest page. They are looking for the sentence they can lift without changing a word.

Priya Raman, research editor

Give the tool something it cannot find elsewhere

If ten pages say the same thing, a tool can cite any of them, and it often picks the one with the strongest name. A small blog wins by adding something the other pages lack: a test you ran, a number you counted, a worked example or a clear method.

That is why our own posts lean on first-hand work. The benchmark numbers we publish exist nowhere else, so a tool that wants them has to cite us.

Mark up who wrote it and when

AI search tools want to tell their readers who said something and how recent it is. Make both easy to find:

Show the author's name on the post, with a link to a profile that lists their experience.
Show the publish date, and the updated date with a note on what changed.
Add structured data for the author and dates, so machines read the same facts that people see.

Write for the reader, then check for the tool

The habits that help AI search are the same habits our SEO writing guide teaches for people: one question per post, the answer near the top, and short paragraphs with one idea each.

Start from the reader's goal. A post that matches what the searcher really wants is the post a tool can quote, because it answers the question that was asked. Then read your draft as a tool would: cover each paragraph under a question heading and ask whether it still answers the question on its own. Maren and I talk this habit through in our first podcast episode.

Questions about AI search

Can I block AI search tools from my blog?

You can. Most AI search tools respect the rules in your robots.txt file, and each names its own crawler; our note on robots rules explains how they work. Blocking them keeps your posts out of their answers, which also means no citations and no visits from them. For a blog that wants readers, we recommend letting them in.

Do AI search tools send visitors?

They send fewer visitors than a top result in ordinary search, because the answer is often enough. The visitors they do send arrive already convinced the page is worth reading, so they stay longer. A citation also puts your brand name in front of every reader who sees the answer. Our post on finding AI visits in your analytics shows how to count them.

Should I write shorter posts for AI search?

No. Write posts as long as the question needs, and make every section easy to quote on its own. A long guide with a clear answer under each heading gives a tool many passages to choose from. A short post with no clear answer gives it nothing to lift.

To see how much of a blog's readers already come from AI tools, read our search traffic charts for one client.

Podcast episode one: put the answer first for AI search

2026-10-23T00:00:00Z

In the first episode of The Ledger, out loud, Priya and Maren talk about one habit: putting the answer first. AI search tools build their replies from short passages on many pages. A passage that answers the question plainly, with its source in view, is far easier to quote than one that warms up for three paragraphs.

Episode one: put the answer first for AI search

Show notes: why the answer first matters

What we cover in this episode:

Why a reply from an AI search tool is built from passages, not whole pages.
How to write an answer capsule: a short, plain answer right under a question heading.
Why a source and a named author make a passage safer to quote.
What to do with the rest of the post once you put the answer first.

Further listening and reading from our blog:

Maren's guide on how to write answer capsules under question headings.
Priya's study of which pages AI tools choose to cite.
Our full guide to being found in AI search, the hub of this series.

Chapters

Why we started a podcast about writing
How an AI answer is put together
The paragraph with the answer first
Sources and names
What the rest of the post is for
One thing to try this week

The transcript

Read the full transcript

Priya: Welcome to The Ledger, out loud. I'm Priya Raman, research editor at Larkspur Studio.

Maren: And I'm Maren Okafor, head of content. We're starting with the habit we ask every writer for: the answer first, everything else after.

Priya: Let's start with why it matters more now. When someone asks an AI search tool a question, the tool doesn't hand back one page. It reads many pages and builds a reply from short passages. Google's own features work like this too, such as the AI Overview at the top of some results.

Maren: So the unit that gets chosen is the passage, not the post.

Priya: Right. Often the tool splits one question into several smaller ones and searches for each. That is called query fan-out. Your page might be picked to answer just one of those small questions.

Maren: Which means each section has to stand on its own. If the answer to "how long should a meta description be" only makes sense after the three paragraphs above it, it is hard to lift out.

Priya: So what does a section with the answer first look like?

Maren: The heading asks the question in the reader's words. The first two or three sentences answer it plainly. No "great question", no history. Then the detail comes after: the reasons, the exceptions, the example.

Priya: How long is that first answer?

Maren: Our house rule is forty to sixty words. Long enough to be complete, short enough to quote whole. Khalid's linter checks it for us, so it never slips.

Priya: And it should make sense out of context. If you read only that paragraph, do you know what "it" refers to?

Maren: That's the test I use most. I copy the paragraph into a blank note. If it still answers the question, it's done. If it says "as we saw above", it's not.

Priya: Let's talk about sources. In my work on how these tools cite pages, the passages they quote tend to state a fact plainly and show where it came from.

Maren: Which is what a good editor asks for anyway.

Priya: Exactly. A number with a link to where it came from is easier to trust than a bare number. And a page with a named author, who has real experience of the subject, gives the reader a reason to believe it.

Maren: Google says much the same. Its guidance on AI features says the usual good practice applies, and there's no special trick. We link it in the notes.

Priya: So nobody needs a separate "AI version" of their post?

Maren: No. Write one good page. Make each section answer one question, plainly, with its source. That serves the skimmer, the search engine and the AI tool at once.

Priya: What about the rest of the post? If you put the answer first, why would anyone keep reading?

Maren: Because the answer is the start, not the whole job. Below it you give what a short reply can't: the worked example, the step-by-step, your own data, the edge cases. That is where you add something new, what we call information gain.

Priya: And that's often what gets a page cited over a dozen others saying the same thing.

Maren: If ten pages give the same answer, the one with a real example from real work has a reason to be chosen.

Priya: Any traps?

Maren: Two. First, writing the question heading and then not answering it. The heading promises, the paragraph dodges. Second, stuffing every section with the same keyword. It reads badly and helps no one.

Priya: And from my side: don't invent numbers to sound precise. If you don't have a source, say it's an example. A made-up figure is worse than none, because once it's quoted, it travels.

Maren: So, one thing to try this week?

Priya: Pick your best post. Find the three questions it answers. Under each heading, rewrite the first paragraph so it answers in a few plain sentences.

Maren: Then copy each one into a blank note and check it still makes sense alone.

Priya: That's it for episode one. Thanks for listening.

Maren: See you next time.

What to do after listening

Pick one post and try the exercise from the end of the episode: the answer first under every question heading. Then read Google's own page on AI features and your website, which Maren mentions. It confirms that good pages need no special treatment to appear in AI search features.

How this page is marked up

This page carries structured data for a podcast episode. It names the episode, its number, the show it belongs to and the audio file, so podcast apps and search engines can place it. Khalid writes it from the post's settings.

The content brief template we use for every post

2026-10-20T00:00:00Z

The content brief template Larkspur Studio fills in before any post is written, section by section, with a finished example you can copy.

Video notes: debugging INP with field data

2026-10-16T00:00:00Z

Debugging INP starts with field data, not with a lab test. Field data tells you which pages feel slow to real readers and on which devices. Then you reproduce one slow tap in Chrome DevTools, split it into its three phases, and fix the phase that takes longest. These are our notes, next to a talk from the Chrome team.

New field insights for debugging INP

What INP measures

Interaction to Next Paint, or INP, measures how quickly a page responds when someone clicks, taps or types. The browser times each of those interactions during a visit, from the input to the next frame painted on screen. The page's score is close to the slowest one. web.dev's guide to INP sets the bands: 200 milliseconds or less is good, and over 500 milliseconds is poor.

On a blog, the slow interactions are rarely in the article. They hide in the menu button, the search box, the cookie banner and the comment form. Our Core Web Vitals guide for writers covers the other two metrics.

Read the field data first

Field data comes from real visits. Lab data comes from one test on one machine. For debugging INP you need both, but in that order, because a lab test only shows what you thought to click.

The Chrome UX Report (CrUX). Google's public set of real Chrome user data. Its documentation explains what it covers. PageSpeed Insights shows it at the top of each report, for the page and for the whole site.
Search Console's Core Web Vitals report. It groups your URLs into good, needs improvement and poor, and names the metric at fault. Google's page on Core Web Vitals and search links to it.
Your own field data. The web-vitals library can send each visit's INP to your analytics, with details on the element that was tapped.

Look for a pattern before you open DevTools. Is it every template, or only pages with comments? Phones only, or desktop too? A group of slow URLs that share one template usually share one cause.

The three phases of an interaction

Every interaction has three parts. Your fix depends on which one is long.

One tap, from finger to frame. Look for the longest of the three bars: it tells you where to start.

Input delay. The time before the page can even start to respond. It is long when the main thread is busy with other work, such as a script still loading.
Processing time. The time the page's own code takes to handle the event. It is long when a click handler does too much at once.
Presentation delay. The time the browser needs to work out the layout and paint the next frame. It is long when the page is huge or a change forces the whole layout to be worked out again.

Common causes on blogs

Cause	Phase it hurts	What to try
Heavy third-party scripts: ads, chat widgets, tag managers	Input delay	Load them later, or drop the ones nobody uses
A large DOM: long comment threads, mega menus	Presentation delay	Paginate comments, simplify the menu
Long tasks from theme scripts	Input delay and processing time	Split work into smaller pieces, defer what can wait
A search box that filters on every key press	Processing time	Wait until the reader pauses before filtering

The DOM is the tree of elements the browser builds from your HTML. Every element in it adds work when the layout changes.

Find a slow interaction with Chrome DevTools

Pick the page and the element

Use the field data to choose a slow page. Guess the likely element: menu, search, banner or form.
Slow the CPU down

Open DevTools, go to the Performance panel and turn on CPU throttling. Your laptop is faster than most readers' phones.
Record the interaction

Start a recording, click the element once, then stop.
Read the Interactions track

Find your click in the Interactions track. Hover over it to see the three phases and which one is longest.
Look at the main thread

Under the interaction, find the long tasks. DevTools marks them with a red corner. Open one to see which script ran.
Fix, record again, then wait

Make one change and record again. Then watch the field data, which takes weeks to catch up.

Keep it fixed

Most INP regressions on blogs arrive with a new widget, not with new writing. Add a check for new third-party scripts to your technical SEO audit, and test the menu and search on a phone after every theme update. Good speed also supports the structured data on your pages and content work you have already done, because a page that responds fast keeps the reader you earned.

Structured data for blog posts, step by step

2026-10-13T00:00:00Z

Structured data is a short block of code that tells search engines, in their own language, what a page is: a blog post, who wrote it, when it was published and what it is about. Readers never see it. Search engines and AI tools read it first, because it saves them from guessing.

This post explains what to put in it for a blog post, how to add it, and how to check that it works.

What structured data does for a post

A search engine can read your page and work out most of the facts. Data in this structured form removes the guesswork. It states the headline, the author, the publish date and the image in a fixed format called schema.org vocabulary, usually written as JSON-LD inside the page.

That certainty pays off in three places:

Search results. The date and the author can appear next to your link, which helps a reader trust it.
Author pages. Linking each post to a person with a profile shows who stands behind the advice.
AI search. Tools that quote pages want to name the author and the date. Clear markup hands them both.

The fields a blog post needs

Google's guide to article markup lists no required fields, only recommended ones. In practice these are the ones that matter for a blog post:

headline: the post's title, as readers see it.
author: a person, with a name and a link to their profile page.
datePublished and dateModified: when the post went live and when it last changed in a way that matters.
image: the lead image, at a good size.
publisher: the organisation behind the blog.

Here is the shape of the markup for one post. The dates and the address are left out to keep it short; a real page fills them in.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Structured data for blog posts, step by step",
  "author": {
    "@type": "Person",
    "name": "Tomas Lindqvist",
    "url": "https://www.example.com/blog/authors/tomas-lindqvist/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Larkspur Studio"
  }
}

BlogPosting on schema.orgEvery property a blog post can carry, with what each one means.schema.org

Hand-written markup or markup from your blog

You can write the block yourself, or let your blogging tool write it from the post's own fields. Each way has its place.

Written by your blog

The markup comes from the title, author and dates you already fill in. It never drifts out of step with the page, and nobody has to remember it.

Written by hand

You can describe things your blog does not know about, such as an event or a product. You also have to keep it correct every time the post changes.

Our advice: let the blog write the markup for every post, and add hand-written blocks only for the rare page that needs more.

Add markup to a post in five steps

Fill in the post's own fields

Give the post a title, an author with a profile page, a publish date and a lead image. Good markup starts with complete fields.
Check what the page already has

Open the page source and search for "ld+json". Many blogging tools add the markup for you, and two copies confuse search engines.
Add only what is missing

If the page has no markup, add one BlogPosting block in the head of the page. Fill in each field from the list above.
Test the page

Paste the address into Google's Rich Results Test. Fix every error, then read the warnings and fix the ones that apply.
Keep the dates honest

Change the modified date only when the content changes in a way a reader would care about. Fixing a typo is not an update.

Why not mark up every page as an article?

Markup has to describe what is really on the page. A category page is a list, an about page is about a company, and a product page is a product. Marking them all up as articles is misleading, and search engines can ignore the markup or the page for it.

Mistakes that make search engines ignore the markup

Most broken markup we see comes from a short list of slips:

Markup that disagrees with the page. The headline in the code says one thing and the page says another.
Authors without a page. A name alone is weak. Link the person to a profile that says who they are.
Dates that change every day. Some tools set the modified date to today on every visit. Search engines learn to distrust it.
Copied blocks. A template copied from another post still names the old title.

Run the test again after every template change. A small change to the theme can break the markup on every post at once.

Where structured data fits with the rest

Markup is one part of how a post presents itself in search. The text people see still does the most work: write a meta description that earns the click and a clear title before you worry about code.

Speed matters too. A page that loads slowly gets fetched less often, so pair this work with the habits in our guide to the three Core Web Vitals. And because AI tools lean on named authors and dates, clear markup is part of how AI search decides what to quote.

The 2026 content benchmark data, free to download

2026-10-09T00:00:00Z

This page shares the benchmark data behind our 2026 content benchmark, in the shape we used to count it. You get a CSV file with one row per blog, a data dictionary that explains each column, our method, and the terms for reuse. Open it in any spreadsheet and run your own counts.

Download the benchmark data

Content benchmark 2026, sample rows (CSV)

The file holds twenty sample rows, not every blog we read in 2026. Each row is one blog, named only by a short code. We never publish the names of the blogs we read. Our news post on opening the data explains why we share it. The full write-up of the findings lives on its own page, the 2026 content benchmark, with five findings and what to fix first.

What the benchmark measured

We read, in 2026, 140 small business blogs, post by post, all in August. We counted only what any reader can see on the page. The headline findings, all from that 2026 read:

Finding	Share of blogs
No author name on posts	61% in 2026
Meta description blank on at least one post in five	54% in 2026
No post updated in twelve months	38% in 2026
A content calendar shared with the whole team	23% in 2026
Numbers in posts linked to a source	19% in 2026

Posts updated within the year earned, in 2026, 1.6 times the search clicks of untouched posts at the median. The sample rows do not hold click data, so you cannot rebuild that figure from this file.

Data dictionary

Each column in the benchmark data, what it holds and the values it can take.

Column	What it means	Values
`blog_id`	A code for the blog, so rows can be cited without naming anyone	A short code, one per blog
`sector`	The kind of business behind the blog	software, professional services, manufacturing, logistics
`posts_published_12m`, counted in 2026	Posts published in the year before the read	A whole number

Show the other columns

Column	What it means	Values
`has_author_names`	Whether most posts show the writer's name	yes, no
`blank_meta_share`	The share of posts we checked with no meta description	A decimal, from none to all
`updated_in_12m`, checked in 2026	Whether any post shows an update in the past twelve months	yes, no
`shared_calendar`	Whether the team said it keeps one calendar everyone can see	yes, no
`sourced_numbers`	Whether most numbers in the posts link to a source	yes, no

The column on updates is our simplest sign of content decay: an archive nobody has touched in a year tends to drift out of date.

Work out a median yourself

A median is the middle value once you sort a column. It suits blog counts better than an average, because one very busy blog can drag an average up. Sort the column of posts published from low to high. With twenty rows there is no single middle row, so take the two middle values and halve their sum.

median = \frac{x_{10} + x_{11}}{2} = \frac{24 + 24}{2} = 24

Median

So the median sample blog published 24 posts (2026), about two a month. That matches the median we reported for the full 2026 read.

Method notes

Who we read. Public blogs of small companies that sell to other businesses, in four sectors. We picked them from client enquiries and public directories, so they are not a random sample.
When. Every blog was read during August 2026. A post counts as updated only if the page shows a date of change.
How. Two editors read each blog. Where they disagreed, a third read it and decided.
One column we asked about. A calendar is not visible on a blog, so shared_calendar comes from a one-line question we sent each team.
What we did not measure. Traffic, rankings and links. Those need access to each site's own tools, which we did not have.

The benchmark data has limits you should keep in mind. Our blogs are small and mostly British. The patterns may not hold for large publishers or other markets.

Licence and reuse

You may share and adapt the benchmark data for any purpose under the Creative Commons Attribution 4.0 licence. The one condition is credit: name Larkspur Studio and link to this page.

Credit us in your own work

Copy this line into your notes or reference list:

Larkspur Studio (2026). Content benchmark 2026, sample rows. Larkspur Ledger. https://www.example.com/blog/content-benchmark-data/

How this page is marked up

This page carries structured data for a dataset. It names the file, its licence, the month it covers and the columns it holds, so dataset search tools can list it. Khalid writes it from the post's settings.

If the numbers prompt you to act, our guides on refreshing posts that slipped and planning a calendar your team will keep are good next steps. The wider content strategy guide puts both in context.

The 2026 content benchmark: what 140 blogs show

2026-10-06T00:00:00Z

The Larkspur content benchmark is our yearly look at how small companies that sell to other businesses run their blogs. During August 2026, 140 of their public blogs went through our hands. We read each one post by post and counted what any reader can see: who wrote each post, when it was last updated, how it answers its question and where its numbers come from.

This is the summary. Members get the full tables by category.

Five findings from the content benchmark

The share of the blogs we read that showed each habit. The longest bar is a gap, not a strength: most blogs left out the author's name.

Finding	Share of blogs
No author name on posts	61% in 2026
Meta description blank on at least one post in five	54% in 2026
No post updated in twelve months	38% in 2026
A content calendar shared with the whole team	23% in 2026
Numbers in posts linked to a source	19% in 2026

Who wrote this post

Readers trust a person more than a logo, and search engines look for signs that a real expert stands behind a page. Even so, most blogs we read in 2026, 61% of them, showed no author at all. Fewer still had an author page with the writer's experience.

The fix the content benchmark points to takes an afternoon: a name on each post, a short bio, and a page per writer that says why they know the subject.

The forgotten archive

The most common habit the content benchmark found was neglect. Blogs kept publishing, but they rarely went back. In 2026, 38% had not changed a single post in the past twelve months, including posts that named prices or tools that no longer exist.

We cannot prove the update caused every extra click. Posts worth updating may have been stronger to begin with. But the pattern held in every category we read, and it matches what we see with clients. Our playbook for posts that slipped shows how to choose which ones to update first.

Planning and pace

The median blog in our sample published, in 2026, 2 posts a month, usually in bursts followed by long gaps. Only 23% in 2026 used a content calendar shared with the whole team. The blogs with a shared plan published at a steadier pace and had fewer gaps longer than two months.

If your team plans in a chat thread, our guide to a calendar a small team can keep is a gentle place to start.

The parts searchers see first

Titles and descriptions are the first thing a searcher reads, and many blogs left them to chance. In 2026, 54% of the blogs left the meta description blank on at least one post in five. Search engines then write their own snippet from the page, which rarely sells the click.

Titles fared better, but many were vague labels like "Our thoughts on pricing". Our post on headlines that earn the click shows what works instead.

Sources and AI search

Only 19% of the blogs in 2026 linked their numbers to a source. That matters more each year. AI search tools prefer passages that state a fact plainly and show where it comes from, so an unsourced number is less likely to be quoted. Read how AI search picks which pages to quote for the full picture, and our guide to writing for AI search for what to change. Sample rows from this study are now free to download.

Members can read the full benchmark tables by category.

You do not need to fix everything at once. Pick the gap that is cheapest to close:

Add author names and bios. An afternoon of work, and it helps every post at once.
Refresh your best old post. Start with the one that once did well and has slipped.
Write the missing descriptions. Ten minutes per post, and you choose what searchers read.
Share one calendar. One sheet the whole team can see, with an owner per post.

Measure the effect the same way we do: count the cost and the results, post by post. Our guide to return on content shows how.

For a much larger view of how content teams work, the Content Marketing Institute's research publishes yearly surveys of marketers.

How to set up Google Search Console in 15 minutes

2026-10-02T00:00:00Z

Google Search Console is Google's free dashboard for site owners. It shows which searches bring people to your blog and warns you when Google cannot index a page. Setting it up takes about a quarter of an hour: add your site, prove you own it, submit your sitemap, then check the reports. This guide walks through each step.

Before you start

You need three things: a Google account, the address of your blog, and access to either your domain's DNS settings or your site's HTML. DNS is the system that points your domain name to your server. You change it where you bought the domain, or wherever your host manages it.

If you cannot reach either one, ask whoever runs your site. Verification is the only step that needs it.

Domain property or URL-prefix property

Search Console offers two kinds of property, which is its word for a site you track. Pick the one that fits your access.

Point	Domain property	URL-prefix property
What it covers	Every version: http, https, www, no www and every subdomain	Only addresses that start with the exact prefix you type
How you verify	A DNS TXT record only	An HTML tag, an HTML file, analytics, a tag manager or DNS
Best for	Owners who can edit DNS	Owners who can edit the site but not DNS
Main drawback	Needs DNS access	Misses data from other versions of the site

We use a domain property for every client site where we can. One property shows all your data, so nothing hides on a version you forgot to add.

Set it up in six steps

Add a property

Open Search Console and sign in with your Google account. Choose Add property. Type your bare domain, such as example.com, in the domain box, or your full address, such as https://www.example.com/, in the URL-prefix box.
Verify that you own the site

For a domain property, copy the TXT record that Search Console shows you. Add it in your DNS settings as a new TXT record on the bare domain, save, and press Verify. For a URL-prefix property, the quickest way is the HTML tag: paste the meta tag into the head of your home page, publish, and press Verify. You can upload the HTML file to your site's root folder instead.
Submit your sitemap

Open Sitemaps in the menu. Type the address of your sitemap, often sitemap.xml, and press Submit. Most blog engines, Khalid included, write this file for you. An XML sitemap lists every page you want found, so Google does not have to guess.
Check the page indexing report

Open Pages under Indexing. It shows how many pages are indexed and lists the reasons others are not. A new site needs a few days before this fills in, so come back at the end of the week.
Inspect one URL

Paste the address of your newest post into the search bar at the top. Search Console tells you if the page is indexed and which main version of the page Google chose. If it is not indexed, press Request indexing.
Add a teammate with restricted access

Open Settings, then Users and permissions, and choose Add user. Type their email address and choose Restricted. They can see most data but cannot change settings or add users. Keep full access for the people who need it.

The verification step for a domain property. Copy the record first, add it at your DNS host and wait a few minutes, then press Verify. If it fails, wait an hour and try again: DNS changes can take time to spread.

Google's help page on how to verify a site you own lists every method and what to do if one fails.

What to look at in the first week

Data in Search Console starts to arrive within a few days. In the first week, look at two things.

First, the page indexing report. If a post you care about is missing, the reason often explains the fix, such as a page marked Noindex by mistake, or a page that redirects.

Second, the performance report. It lists the searches that showed your pages, with clicks and impressions. Do not judge anything yet. Come back after a month, when there is enough data to see a pattern. Our post on what searchers want from a page shows how to read those searches and plan the next post.

Questions about Search Console

Is Google Search Console free?

Yes. Search Console is free for every site, with no paid plan. You only need a Google account and a way to prove you own the site. It does not change how Google ranks your pages: it shows you what Google already sees, so you can fix problems and spot what works.

How long does verification take?

An HTML tag or file usually verifies at once, as soon as the page is live. A DNS record can take longer, because changes take time to reach every server. If verification fails, wait an hour and press Verify again before you look for a mistake in the record.

Should I also set up Bing Webmaster Tools?

Yes, once Search Console is running. Bing's tool is free and can import your sites from Search Console, so it takes a few minutes. It adds link and keyword reports. Our comparison of the two tools explains where each one wins.

Once you are set up, see our seven picks of free tools for a small blog for what to add next, or read our guide to choosing SEO tools for the full kit.

Core Web Vitals explained for content writers

2026-09-29T00:00:00Z

Core Web Vitals are three measures Google uses to judge how a page feels to the person reading it: how fast the main content appears, how quickly the page responds to a tap, and whether things jump around while it loads. Writers rarely touch the code, yet most of what slows a blog post down is something a writer added.

This post explains each measure in plain words, shows the scores that count as good, and lists the habits that keep your own posts fast.

What the three Core Web Vitals measure

Each measure answers one question a reader would ask if they could.

Does the page show up soon? That is the largest contentful paint, the moment the biggest image or text block on the screen appears.
Does it react when I tap? That is Interaction to Next Paint, or INP. It times the gap between a click or tap and the next change on the screen.
Does it stay still? That is Cumulative Layout Shift, or CLS. It adds up how far things move while the page is still loading.

The largest contentful paint is the third frame: the moment the biggest element on the screen has arrived.

The scores that count as good

Google groups each of the Core Web Vitals into good, needs improvement and poor. A page passes when most real visits score good. The table shows the line for good, from the Web Vitals guide on web.dev.

Measure	What it times	Good score
LCP	The largest element appears	In 2026, 2.5 seconds or less
INP	The page answers a tap	In 2026, 200 milliseconds or less
CLS	The layout stays still	In 2026, 0.1 or less

The scores come from real visits, not from a test on your own laptop. Google takes the score that three visits in four beat, so the slowest quarter of your readers decides the result.

Why writers move these scores more than they think

A developer sets up the template once, and it rarely fails the Core Web Vitals on its own. A writer adds new things to it every week: a lead image, a chart, an embedded video, a quote from a social network. Each of those is a request the browser must make before the page feels finished.

The biggest one is almost always the lead image. On most posts it is the largest element on the screen, so its size decides the largest contentful paint. A photo saved straight from a camera can be ten times heavier than it needs to be.

Habits that keep a post fast

These are the habits we ask of every writer at Larkspur. None of them needs a developer.

Resize before you upload. Match the widest size your template shows, and no more.
Pick the right format. Use photos as JPEG or WebP and drawings as SVG.
Describe every image. Alt text costs nothing in speed and helps every reader who cannot see the picture.
Load embeds only when needed. One video in a post is fine. Four videos and a social feed are not.
Keep the top of the post light. The first screen should be text and one image, not a slider.

If your blog lets you write an image tag by hand, keep the browser's own lazy loading for images further down the page, and always give the alt text:

<img src="reader-survey-chart.webp"
     alt="Bar chart of the questions our readers asked most"
     loading="lazy" decoding="async">

Do not lazy load the lead image. It is the one image the reader needs at once, so the browser should fetch it first.

Layout shift, the problem readers notice most

A page that jumps while you read it is the fastest way to lose trust. You start reading a line, an advert or an image loads above it, and the line moves away from your eyes.

Most layout shift in posts comes from three sources:

Images without a set size. The browser does not know how much room to keep, so it makes room late.
Embeds that grow as they load. A video or a social post often starts small and then expands.
Banners added at the top. A notice that slides in after the page has drawn pushes everything down.

A good template reserves the space for each of these before they load. If your blog shows the width and height of every image, the browser can do the same.

Watch the talk on responsiveness

The Chrome team explains in this talk from 2024 how to find the slow interactions behind a poor INP score, with examples from real sites.

New field insights for debugging INP

Our video notes on debugging INP pull out what to check on a blog. This post also has a German version, and our step-by-step guide for a two-language blog shows how the two are tied together.

Check your own Core Web Vitals

You do not need special tools to see where you stand. Search Console has a Core Web Vitals report that groups your pages by score from real visits. Check it once a month, and look first at the posts with the most traffic.

When a post fails, open it and ask which of the habits above it breaks. In our experience the fix is the lead image four times out of five. Fast pages also help when you mark up a post with structured data, because a page that loads quickly gets crawled and read more often.

Add a speed check to the list we run before every post, so the problem never reaches your readers. And if you write for AI search as well, fast and stable pages are easier to fetch: our research on which pages AI tools choose to quote shows why.

The 7 best free SEO tools for a small blog

2026-09-22T00:00:00Z

Our top pick is Google Search Console: every blog that wants search traffic should set it up first, because it shows how Google sees your pages. The runner-up is Bing Webmaster Tools, a second free view with link and keyword reports. The other five free SEO tools each fix one job well.

The picks at a glance

Pick	Best for	Price	Why it made the list
Google Search Console	Every blog	Free	Google's own data on your pages
Bing Webmaster Tools	A second view	Free	Links, keywords and quick indexing
PageSpeed Insights	Checking one page's speed	Free	Lab and real-user speed data in one report
Rich Results Test	Google rich results	Free	Shows which rich results a page can get
Schema Markup Validator	Any schema.org markup	Free	Checks every schema.org type
Screaming Frog SEO Spider	Crawling a small site	Free for small sites	Finds broken links and missing titles fast
Google Trends	Timing a topic	Free	Shows when interest in a topic rises

Google Search Console

Who it suits: every site owner, from the first post onwards.

What it does best: it shows the searches that bring people to your pages, with clicks, impressions and average position. Its page indexing report tells you which pages Google left out and why. Its URL inspection tool shows how Google sees one page.

Main limit: it covers Google only, and it gives no new keyword ideas. It only shows searches where your site already appears.

Price: free. Read Google's overview of Search Console, then follow our 15 minute setup guide.

Bing Webmaster Tools

Who it suits: anyone who already has Search Console and wants a second view.

What it does best: it adds what Google's tool leaves out, which makes it one of the most useful free SEO tools after Search Console. You get a free report of sites that link to you, a keyword research tool with Bing's own search counts, and support for IndexNow, an open way to tell search engines about a new page at once.

Main limit: it reports on Bing's audience, which is smaller than Google's, so a small blog sees less data.

Price: free, and it can import your sites from Search Console. We weigh the two in our side-by-side look at both webmaster tools.

Bing Webmaster ToolsMicrosoft's free dashboard for site owners.www.bing.com

PageSpeed Insights

Who it suits: a writer or owner who wants to know if one page is slow, and why.

What it does best: paste a URL and it gives two views. Lab data comes from a test run on the spot. Field data shows how the page loaded for real Chrome users, including how long the main content takes to appear. Under the scores it lists what to fix first.

Main limit: it checks one page at a time, and field data only appears when a page gets enough visits. A quiet post on a new blog shows lab data only.

Price: free. Our guide to the Core Web Vitals in plain words explains how to read the report.

PageSpeed InsightsGoogle's free speed report for any page.pagespeed.web.dev

Rich Results Test

Who it suits: anyone who adds FAQ, review, recipe or article markup and wants it to show in Google.

What it does best: it tells you which Google rich results a page can show, such as review stars or recipe cards, and points to any error that blocks them. You can test a live URL or paste code.

Main limit: it only checks the types Google supports. Valid markup of another type gets no comment at all.

Price: free, at the Rich Results Test page.

Schema Markup Validator

Who it suits: anyone who writes markup by hand or uses types that Google does not show as rich results.

What it does best: it checks markup against the whole schema.org vocabulary, not just Google's part of it. It shows each item it found in a tree, so you can see what a page says about itself.

Main limit: it tells you nothing about how Google will show the page. Use it beside the Rich Results Test, not instead of it: one checks the vocabulary, the other checks what Google will show.

Price: free, run by schema.org on the schema.org validator site.

Screaming Frog SEO Spider

Who it suits: a blog with enough posts that you can no longer check every page by hand.

What it does best: the Screaming Frog crawler visits your site the way a search engine does and lists every page with its status, title, description, headings and links. In a few minutes you can find broken links, missing titles and pages that redirect.

Main limit: unlike most free SEO tools here, it is a desktop app with many settings, so it takes an hour to learn. Some features, such as saving a crawl, need the paid licence.

Price: the free version crawls up to 500 URLs, which Screaming Frog states on its own page. That covers most small blogs.

Google Trends

Who it suits: a writer planning when to publish, or choosing between two ways to name a topic. Of all the free SEO tools here, it is the one to open before a post is written.

What it does best: it shows how interest in a search term rises and falls over time and by region. It is good for spotting a season, such as a topic that peaks every January, and for comparing two phrases.

Main limit: it shows interest relative to the busiest point, not the number of searches. Use it for timing and comparison, not for sizing a topic.

Price: free, at Google Trends.

How we chose these free SEO tools

We picked free SEO tools that a small blog can use without paying and without a trial that ends. Every pick had to do one job better than the free part of any paid suite we know. Dalia Moreno, our tools and reviews editor, used each one on Larkspur's own site in September 2026, and Tomas Lindqvist checked the technical claims.

We left out tools that only show data after you sign up for a paid plan, and free SEO tools that do the same job as a pick above. Nobody paid to be on this list, as our policy on reviews and money explains. If you want a writing tool too, see our review of the Quillmeter readability checker, and for the bigger picture on free and paid SEO tools, read how we choose tools for a small team.

A content refresh playbook for posts that slipped

2026-09-15T00:00:00Z

A content refresh is the work of bringing an old post back up to date so it serves readers again: new facts, a clearer answer, better links. It is the cheapest growth most blogs ignore. Writing a new post starts from nothing. A refresh starts from a page that search engines already know.

This playbook shows how we choose which posts to refresh, what we change, and what we leave alone.

Why old posts slip

Posts lose ground for ordinary reasons. The facts change. A tool gets renamed. Competitors publish something clearer. Readers' questions shift. None of this shows on the post itself, which looks exactly as it did on the day you published it.

The cost of leaving posts alone is real. Our benchmark found that in 2026, 38% of small business blogs had not updated a single post in twelve months. Posts updated within the year earned, in 2026, 1.6 times the search clicks of untouched posts at the median. A content refresh is how a blog collects that gain.

A blog is not a stack of finished pages. It is a garden, and the oldest beds need the most weeding.

Priya Raman, research editor

Find the posts worth a content refresh

Not every old post deserves your time. Look for posts that once did well or that answer a question your customers still ask. Three signals point to the best candidates:

Falling clicks. The post's search clicks are lower than they were a year ago.
Near misses. The post shows up in results often but sits just below the top few places.
Out-of-date facts. The post names a year, a price or a tool that has changed.

Sort your posts by these signals and pick a few per month. A steady habit beats a big rewrite project. We keep a refresh slot every second week in the calendar our team plans with, so the work never waits for a quiet month.

Decide what each post needs

A content refresh can be small or large. Match the work to the problem:

Problem	What to do
Facts out of date	Replace them and cite the new source with its year
Answer buried	Move a short answer to the top
Thin on detail	Add an example, a table or a step list
Wrong question	Rewrite around the question readers ask now
Overlaps a newer post	Merge the two and redirect the weaker one

Run the refresh in seven steps

Read the post as a stranger

Read it top to bottom on a phone. Note every place where you would stop reading or stop trusting it.
Search its question again

Search the question the post answers and read the top results. Note what they cover that your post does not.
Check what AI search says

Ask an AI search tool the same question. See which pages it quotes and what kind of answer it gives.
Update the facts and sources

Replace every number, name and screenshot that has changed. Give each new number its source and its year.
Sharpen the answer

Put a plain answer near the top. Cut sections that no longer earn their place.
Refresh the links

Link to posts you have written since, and check that every outside link still works.
Show the date and say what changed

Set the updated date, and write one sentence at the top that tells readers what is new.

Before a content refresh goes live, run the post through the editors' pre-publish checklist. A refresh deserves the same care as a new post.

Tell readers what changed

An updated date on its own can look like a trick. Readers have seen posts whose date changes every month while the text stays the same. Be specific instead. One sentence at the top, such as "We added the new pricing and a section on exports", tells readers the update is real.

Google's guidance on showing dates in search results asks for the same honesty: change the date only when the content really changes.

Measure whether it worked

Write down the post's clicks and results before you change it. Check again after six to eight weeks, and compare the same length of time before and after. Some posts climb fast. Others need a second pass.

Make the content refresh a habit

The teams that get the most from old posts do not run a big project once a year. They keep a short list, refresh a few posts each month, and treat the archive as part of the blog rather than its attic. Start with the post that once did best and has slipped the most. It is usually the fastest win you have.

If you are new to the craft behind a strong post, start with the full SEO writing guide. Every refresh is easier when you know what a good post looks like.

How to write answer capsules AI search can quote

2026-09-09T00:00:00Z

An answer capsule is the short, plain answer you write straight under a heading that asks a question. It is the part of a post most likely to be lifted whole, by a reader in a hurry, by a featured snippet, or by an AI search tool building its reply. This post shows how we write answer capsules, with before and after examples from our own drafts.

It is part of our guide to being found in AI search, which covers the wider picture. If you want the one-line version first, read the glossary entry for this term.

What is an answer capsule?

An answer capsule is a short, plain answer placed directly under a heading that asks a question. It runs forty to sixty words, makes sense on its own, and settles the question before any detail starts. A reader in a hurry can stop there. A search tool can lift it whole and quote it without edits.

Why forty to sixty words

Shorter than that and the answer has no room for the one condition or example that makes it useful. Longer and it starts to carry two ideas, so a tool that quotes it has to cut. The range is a house rule, not a law of search. Our blog engine checks it on every post: you can see the check at work in our tour of the linter and editor.

Why do AI search tools quote answer capsules?

AI search tools build their replies from short passages they can lift from a page. A passage that answers the question in full, names its subject, and needs no sentence before it to make sense is easy to lift. An answer capsule is built to be that passage, so you give the tool a clean one to quote.

The same capsule serves featured snippets

A Featured snippet is the boxed answer Google sometimes shows above the usual results. It draws on the same kind of passage: a direct answer under a clear heading. Google's page on how featured snippets work says the snippet is chosen automatically, and that you cannot mark up a page to ask for one. What you can do is write the answer so it is easy to choose.

Our post on how AI search picks the pages it cites makes the same point. The easiest passage to quote is one that stands alone under a question heading.

How do you write an answer capsule?

Start with the question as a heading, in the words a reader would type. Under it, answer in the first sentence, using the subject's name instead of a pronoun. Add one or two sentences of the most useful detail: a condition, a number or a next step. Stop at sixty words, then move the rest below.

Before and after

Here is a capsule from one of our own drafts, before and after the edit. The question was "Should a blog post have a table of contents?"

Before

Tables of contents have been around for a long time, and opinions on them vary a lot. In our experience, it really depends on the post. That said, there are some cases where they can arguably help, as we will explore in the sections below.

After

Yes, for any post long enough to need scrolling. A table of contents lets a skimmer jump to the part they need, and it gives search engines named links into each section. Skip it on short posts, where it only pushes the answer further down the page.

The first version never answers. The second says yes in its first word, gives the reason, and names the exception. Nothing in it depends on the paragraph before.

A checklist for every capsule

The heading is a real question and ends with a question mark.
The first sentence answers it, and would make sense read aloud on its own.
The subject is named, not "it" or "this".
The answer runs forty to sixty words.
No hedge words, no links, and no "as mentioned above".
The detail, the caveats and the examples sit below the capsule, not inside it.

What mistakes stop a capsule being quoted?

Three mistakes do most of the damage. Hedging makes the answer sound unsure, so readers and tools have less reason to trust it. Burying the answer behind a warm-up sentence means the passage no longer stands alone. A link in the first sentence pulls the reader away before they have the answer, and breaks the flow.

The mistakes in detail

Mistake	Example	Fix
Hedging	"It can arguably help in some cases."	Say what you know: "It helps on long posts."
Burying the answer	"Before we answer, some history."	Put the answer first, history after.
A link in the first sentence	"As [our guide] shows, yes."	Answer first, link in the detail.
Leaning on the post	"As we said above, no."	Restate the subject so it stands alone.
Two questions at once	"Yes, and also you should..."	Give the second question its own heading.

Our linter flags the common hedge words under question headings for this reason: "arguably", "basically", "perhaps" and their cousins. Each one makes the answer weaker and adds nothing a reader needs.

The shape of a section built around a capsule. Notice that the capsule sits between the question and the detail, so a tool can lift it without taking anything else.

Questions about answer capsules

Does every post need answer capsules?

No. Use them where a heading asks a real question. A step-by-step guide or a story needs few of them, while a post that answers common questions may have five or six.

Can a capsule hold a list?

Keep the capsule itself as a paragraph, so it can be quoted as one passage. Put a list straight after it if the answer has steps or parts.

Should answer capsules be written for AI or for readers?

For readers. A plain answer near the top helps a person in a hurry, and the same qualities make it easy for a tool to quote. If the two ever pull apart, write for the person.

Google Search Console vs Bing Webmaster Tools

2026-09-08T00:00:00Z

Every blog should set up Google Search Console first, because Google sends most search visits. Add Bing Webmaster Tools next if you want a second view of your site, quick indexing through IndexNow, and a few extra reports for free. Both are free, and Bing Webmaster Tools can import your sites from Search Console in minutes.

Pick Google Search Console if

You can only set up one tool. It shows how the search engine most of your readers use sees your site, and it is where Google tells you about problems.

Add Bing Webmaster Tools if

You want a second opinion on indexing, a way to tell search engines about new pages at once, and free reports on links and keywords.

Google Search Console and Bing Webmaster Tools at a glance

Both tools are free dashboards from the search engines themselves. You prove you own the site, and they show you how their search engine crawls, indexes and shows your pages. The table sets them side by side.

Point	Google Search Console	Bing Webmaster Tools
Best for	Every site, as the first tool to set up	A second view, and quick indexing
Price	Free	Free
Main strength	Data from the search engine most readers use	Extra free reports and IndexNow support
Main limit	Shows Google data only, with no keyword ideas	Smaller search audience, so less data on a small site
Proving you own the site	DNS record, HTML file, meta tag and other ways	DNS record, XML file, meta tag, or import from Search Console
Search data	Clicks, impressions, click rate and position	Clicks, impressions, click rate and position
Indexing tools	Page indexing report, sitemaps, URL inspection	Index reports, sitemaps, URL inspection, IndexNow
Extras	Core Web Vitals report, links report, manual actions	Backlink data, keyword research, a site scan

Where Google Search Console wins

It shows the search engine your readers use most. Google holds by far the larger share of search, so for most blogs its data covers most of the people who find you through search. If a post drops, this is where the drop shows up first.

Google tells you about problems here. If Google takes a manual action against a page, or finds a security issue such as hacked content, it reports it in Search Console. There is no other place to get that notice from Google.

Its page indexing report explains why a page is left out. For each page Google knows about but does not index, the report gives a reason, such as a Noindex tag, a redirect or a duplicate. You can then fix the cause and ask Google to check again.

It reports Core Web Vitals from real visits. The report groups your pages by how fast they load and respond for real Chrome users. Our post on Core Web Vitals explained for writers explains what each one means.

You can check every point above in Google's own overview of the tool.

Where Bing Webmaster Tools wins

It supports IndexNow. IndexNow is an open way to tell search engines that a page is new, changed or gone, the moment it happens. Bing and several other engines take part. Google Search does not use IndexNow, so this is a reason to use Bing's tool, not a reason to drop Google's.

It imports your sites from Search Console. If you already use Google's tool, you can sign in, choose import, and your verified sites and sitemaps come across. There is no new file or DNS record to add.

It shows links from other sites for free. The backlinks report lists sites that link to yours, with the pages and the link words. A Backlink report like this usually needs a paid tool.

It has a free keyword research tool. You can look up how often people search a phrase on Bing and see related phrases. The numbers are Bing's own, so treat them as a rough guide to demand, not as the whole market.

Its data reaches past Bing. Bing's index also powers some other search services, so the indexing problems it shows you can affect more than Bing alone.

Microsoft lists the features on the Bing Webmaster Tools about page.

Which one to choose

A new blog with little time. Set up Google's tool this week and nothing else yet. Our 15 minute setup guide walks you through it, step by step.

A blog that publishes often. Add Bing Webmaster Tools and turn on IndexNow, through your platform or a plugin, so new posts get found the day they go live.

A blog with no budget for paid tools. Use both. Lean on Google for search data and indexing, and on Bing Webmaster Tools for links and keyword ideas. Together they cover much of what a paid suite gives a small site.

A team that must explain results to a client. Report from Search Console, and check Bing Webmaster Tools once a month for problems Google's tool did not show.

How we compared them

Tomas Lindqvist, our technical SEO lead, has used both tools on Larkspur's own site and on client sites since 2024. Dalia Moreno checked every point in the table against each tool's own pages in September 2026.

We compared only features that both search engines document and that a small blog would use:

What we checked	How we checked it
Features	Each tool's own help pages, read in September 2026
Setup	Adding and verifying a test site in each tool
Daily use	Two years of use on our own site and client sites
Accuracy	A second editor checked every row of the table

We did not compare numbers between the two tools, because each one counts clicks and impressions in its own way. We do not take payment from Google or Microsoft, and neither saw this post before it went live. You can read the rules our editors follow in full.

Features change. If you find a point in this post that is no longer true, write to our editors and we will fix it.

How to measure content ROI without a data team

2026-09-01T00:00:00Z

Content ROI is the return a blog post brings back for the time and money it cost to make. You do not need a data team or an expensive dashboard to measure it. You need a spreadsheet, an honest count of hours, and an agreement on what a good result is worth.

This post shows the method we use with small teams. It takes about an hour to set up and a few minutes a month to keep.

Decide what a result is worth

Before you count anything, agree on what a post is for. A blog post can earn its keep in a few ways:

Leads. A reader asks for a demo, books a call or fills in a contact form.
Sign-ups. A reader joins your newsletter or starts a free trial.
Sales help. Your sales team sends the post to a prospect to answer a question.
Support saved. A help question gets answered by a post instead of a person.

Pick the one or two that matter most to your business, and put a rough value on each. Content ROI only works when everyone agrees on these values first. If one in ten demo requests turns into a customer worth a known amount, a demo request is worth a tenth of that. Rough is fine. A rough number you use beats a perfect number you never agree on.

Count the cost honestly

The cost side of content ROI is mostly time. Count every hour, not just the writing:

Planning and the brief
Research and interviews
Writing the first draft
Editing and fact checks
Images, layout and publishing
Refreshing it later

Multiply the hours by a fair hourly cost for the people involved. Add anything you paid for: freelance help, stock images or tools used only for that post. Teams that skip the editing and planning hours make their content look cheaper than it is, and then wonder why the numbers do not add up.

The formula for content ROI

The sum is the same one any investment uses. Take what the post brought in, subtract what it cost, and divide by what it cost:

ROI = \frac{value of results - cost of the post}{cost of the post} \times 100

Return on content

A result above zero means the post paid for itself. A result below zero means it has not yet, which is normal for a young post. Search traffic grows over months, so judge a post on its first year, not its first week.

Track content ROI in one spreadsheet

Make one row per post and one column per thing you count. Keep a column for the publish date, the hours, the cost, each kind of result, and the value. The return column then works itself out. If the value of results sits in column E and the cost in column D, the return for a row is:

=(E:E-D:D)/D:D

Most spreadsheet apps accept whole-column ranges like these. Write the formula once and fill it down. Every month, add the new results from your analytics and your sales notes. It takes ten minutes when the habit is set.

Read the numbers with care

A spreadsheet can mislead as easily as it can help. Three habits keep content ROI honest:

Give each post time. Compare posts of the same age. A two-month-old post will lose to a two-year-old one every time.
Count assists. A reader may find you through a post and buy weeks later through another page. Ask new customers how they found you, and give the post credit when they name it.
Count the cost of refreshing. An update has a cost too, and it often has the best return of any work on the blog.

That last point is why we budget time for old posts. Our playbook for refreshing posts that slipped explains how to choose which ones to update first.

Pros

Uses tools the team already has
Takes about an hour to set up
Makes the case for content in plain numbers

Cons

Values are rough guesses at first
Misses readers who buy much later without saying how they found you
Needs a monthly habit to stay current

Turn the numbers into decisions

The point of measuring content ROI is to choose better next time. Once a quarter, sort the sheet by return and look at the top and the bottom.

Top posts. What do they share? A topic, a format, a kind of question? Plan more posts like them.
Bottom posts. Were they the wrong question, or the right question answered badly? A weak answer can be refreshed. A wrong question can be dropped.
Missing posts. Which questions from sales and support have no post yet? They are often the cheapest wins.

Feed those choices straight into your content calendar for the next quarter, so the plan follows the evidence instead of the loudest idea in the room.

A worked example

Here is how one row looks for a fictional software company. A how-to post took eighteen hours from brief to publish, at a fair cost per hour. In its first year it brought six demo requests and forty newsletter sign-ups. The team valued each demo request and each sign-up using their own sales numbers, added the two values, subtracted the cost and divided by the cost.

The content ROI was well above zero. The post paid for itself about three times over in its first year. The same sheet showed that two other posts had not earned their cost, and both answered questions nobody had asked the sales team. The team dropped one and rewrote the other around a real customer question.

For the wider theory of measuring marketing returns, Google's guide to setting up key events in Analytics explains how to count the results you choose.

To see where the readers behind those results come from, our three monthly search traffic charts show the visits by month, by page and from AI search.