Larkspur Ledger

News: our 2026 benchmark data is free to download

Priya Raman — Sat, 31 Oct 2026 00:00:00 +0000

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.

AI referral traffic: finding AI visits in analytics

Priya Raman — Fri, 30 Oct 2026 00:00:00 +0000

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.

How AI search chooses the pages it quotes

Priya Raman — Tue, 27 Oct 2026 00:00:00 +0000

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.

Podcast episode one: put the answer first for AI search

Priya Raman — Fri, 23 Oct 2026 00:00:00 +0000

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

Maren Okafor — Tue, 20 Oct 2026 00:00:00 +0000

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

Tomas Lindqvist — Fri, 16 Oct 2026 00:00:00 +0000

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

Tomas Lindqvist — Tue, 13 Oct 2026 00:00:00 +0000

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

Priya Raman — Fri, 9 Oct 2026 00:00:00 +0000

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 file, 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 file 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

Priya Raman — Tue, 6 Oct 2026 00:00:00 +0000

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 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 we 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

Tomas Lindqvist — Fri, 2 Oct 2026 00:00:00 +0000

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

Tomas Lindqvist — Tue, 29 Sep 2026 00:00:00 +0000

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 score 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. 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

Dalia Moreno — Tue, 22 Sep 2026 00:00:00 +0000

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.

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 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

Priya Raman — Tue, 15 Sep 2026 00:00:00 +0000

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

Maren Okafor — Wed, 9 Sep 2026 00:00:00 +0000

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

Tomas Lindqvist — Tue, 8 Sep 2026 00:00:00 +0000

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

Priya Raman — Tue, 1 Sep 2026 00:00:00 +0000

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.

Hreflang for a two-language blog, step by step

Tomas Lindqvist — Mon, 31 Aug 2026 00:00:00 +0000

Hreflang is a short tag that tells search engines a page exists in other languages, and where each version lives. Get it right and a reader in Hamburg sees the German post while a reader in Leeds sees the English one. Get it wrong and search engines quietly ignore the lot.

We run this blog in English and German, so we have made most of the hreflang mistakes ourselves. This post shows the tags on our own pages, the rules behind them, and the errors we see most in audits. It belongs to our full technical SEO audit, where language tags are one check among many.

What hreflang tells search engines

A translated post is a set of language versions: pages that say the same thing to different readers. The tag names every member of that set and its language. Google can then pick the version that suits the person searching, and show it in place of the others.

The glossary entry on language tags has the short version. The details below are from Google's guide to localised versions of your pages, which is the reference we check against.

The rules every set of tags must follow

Google's rules are few, and each one matters. Break one and the whole set can be dropped.

Name every version, including the page itself. A page that leaves itself out of its own list is a common slip.
Return links are required. If page A points to page B, page B must point back to A. Without the return link, Google ignores the pair.
Use full addresses. Write the whole address with the domain, not a path that starts with a slash.
Codes follow two standards. The language comes first, as a two-letter ISO 639-1 code. A region can follow, as an ISO 3166-1 Alpha 2 country code, so de is German and de-AT is German for readers in Austria.
Add a fallback. The value x-default names the page to show when no version matches the reader's language.

Our own example: one post in two languages

Our post on Core Web Vitals for writers has a German translation at /khalid/templates/classic/de/core-web-vitals/. You can browse every German post from our German home page. Both versions of that post carry the same three lines in the head of the page:

<link rel="alternate" hreflang="en" href="https://www.example.com/blog/core-web-vitals/">
<link rel="alternate" hreflang="de" href="https://www.example.com/blog/de/core-web-vitals/">
<link rel="alternate" hreflang="x-default" href="https://www.example.com/blog/core-web-vitals/">

The lines are the same on both pages. That is the point: each page names itself, names the other, and names the fallback. Our fallback is English, because a reader whose language we do not cover is more likely to read English than German.

Each page points at itself and at its partner, and both name the English page as the fallback. Notice that the arrows run both ways: remove one and Google can ignore the pair.

Where to put the tags

Google reads the same information from three places. Pick one and use it everywhere, so you have one list to keep in step.

Place	Best for	Watch out for
Link tags in the page head	Most blogs	Every template must print them
HTTP headers	Files such as PDFs that have no head	Needs access to the server settings
The sitemap	Large sites with many versions	The file grows fast with each language

If you choose the sitemap route, each address lists its partners inside its own entry. Our guide to what belongs in an XML sitemap covers the rest of that file. We link the sitemap format in the glossary if you need a primer.

Set up hreflang on a two-language blog

List each pair

Make a sheet with one row per post: the English address in one column and its translation in the next. Leave the second cell empty where there is no translation yet.
Choose your codes

Use plain language codes, such as en and de, unless you write different versions for different countries. Most blogs do not need a region.
Pick the fallback

Choose the version to show readers in other languages. For most blogs that is the original language.
Add the tags to both pages

Put the full set on every version, including a line for the page itself and one for the fallback.
Check the return links

Open each translated page and confirm it names its partner. A missing return link is the most common reason a set is ignored.

Common hreflang mistakes and their fixes

Mistake	What happens	Fix
The page leaves itself out	The set is incomplete	Add a line for the page itself
No return link	Google ignores the pair	Add the tag to the partner page too
`en-UK` as a code	The region code is not valid	Use `en-GB`
A region on its own, such as `gb`	Read as a language code, not a country	Start with the language: `en-GB`
A canonical tag points to the other language	The two signals clash	Point each page's canonical at itself
A tag points to a redirect or an error	That version is dropped	Point it at the final, live address

The canonical mistake deserves a word. A canonical address tells search engines which page is the real one among copies. A German translation is not a copy of the English post, so each version should name itself as canonical.

What the tags do not do

Hreflang helps Google choose which version to show. It does not merge the versions, and it does not lift either one up the rankings. A good translation still has to earn its place.

The tags also do not stop Google treating two near-identical pages in the same language as duplicates. If you publish one English post for readers in Britain and one for readers in Ireland, and only the spelling differs, expect one of them to be picked as the main version. Hreflang still helps Google show the right address, but the content itself must differ enough to justify two pages.

Quillmeter review: a readability checker for editors

Dalia Moreno — Tue, 25 Aug 2026 00:00:00 +0000

Quillmeter suits editors and solo writers who want a quiet readability checker that marks long sentences and rare words and leaves the fixing to them. Skip it if you want a tool that rewrites for you, or if a whole team must share one set of rules. Our score after six months of daily use: four out of five.

What it does well

Quillmeter does one job and stays out of the way. You paste a draft or open a file, and it marks two things: sentences that run long, and words most readers rarely meet. It does not suggest new words. It does not score your "tone". It shows you where a reader may stall, and you decide what to do.

That restraint is the main reason we kept it. Tools that rewrite for you tend to flatten a writer's voice, and they make it easy to accept a change you did not read. With Quillmeter the writer stays in charge of every word, which is how we want our editors to work on the sentence step of our editing checklist.

Three more things stood out in our own use:

It is fast. On the longest guide we edited this year, the marks kept up with our typing. We never waited for a check to finish.
It works offline. We edited two client drafts on a train with no signal, and every check still ran. Nothing leaves your machine, which matters when a client has not yet published.
The limits are yours to set. You choose how many words make a sentence "long". We set ours at twenty-five words, and Quillmeter marked exactly the sentences we would have marked by hand.

Where it falls short

No readability checker is perfect, and Quillmeter has two clear gaps. Each one cost us time on real work.

It treats technical terms as problems. On a post about structured data for a client, Quillmeter marked "schema", "markup" and "canonical" in almost every paragraph. Those are the words a specialist reader expects. You can add words to a personal list so it stops marking them, but you have to do it one word at a time, and the list does not travel with the draft.

It has no team settings. Each copy of Quillmeter keeps its own limits and word list. When three of our editors checked the same draft, they saw different marks, because one had set a lower limit for long sentences than the other two. We now keep the settings in a shared note and copy them by hand, which is a workaround, not a fix.

Two smaller points. It reads plain text and common document files, but it cannot check a page straight from a website, so you copy the text out first. And it does not know anything about search: it will not tell you if a heading matches what the searcher wants. That is fine, as long as you know it is a writing tool and not an SEO tool.

Pros

Marks long sentences and rare words in place, and never rewrites
Fast, even on a long draft
Works offline, so drafts stay on your machine
You set your own limit for long sentences

Cons

Marks technical terms as rare words, even where the reader expects them
No shared settings, so a team sees different marks on the same draft
Cannot check a live web page

Who Quillmeter is for

Quillmeter fits a writer or editor who already knows what good prose looks like and wants a second pair of eyes for the slips. If you edit other people's drafts every day, it saves you the tedium of counting words in long sentences. If you write alone, it catches the habits you no longer notice.

It fits less well in two cases. A team that needs one shared standard will fight the missing settings. And a writer in a technical field will spend a lot of time teaching it words. If you are still choosing between kinds of tools, start with our guide to choosing SEO tools for a small team, which puts writing tools beside search tools.

How we tested it

Dalia Moreno, our tools and reviews editor, used Quillmeter every working day from February to August 2026. Two other editors used it on the same drafts so we could compare their marks.

We ran it on about fifty drafts: most were client work, and a dozen were our own posts. For each draft we wrote down where Quillmeter marked a sentence and whether we changed it. We also counted the marks we ignored, which is how we found the gap with technical terms. We did not run speed tests in a lab: our notes on speed come from ordinary use on a three-year-old laptop.

We judged it on four points: does it find the sentences a good editor would find, does it keep the writer in charge, is it quick enough to leave open all day, and does it fit how a team works. It scored well on the first three and poorly on the last.

If you want a wider view of what to look for in a writing tool, our short notes on the tools we use cover the rest of our kit, and our pick of free tools for a small blog covers the search side.

The verdict

Quillmeter is the readability checker we open first. It marks long sentences and rare words without taking the pen from the writer, it is quick, and it works anywhere. It loses a point for marking technical words a specialist reader expects, and for having no shared settings. For a solo writer or a careful editor, it earns its place. For a team that needs one standard, wait for team settings.

Quillmeter

4 / 5

A fast, quiet readability checker that marks long sentences and rare words in place and leaves every change to you. It works offline. It loses a point for treating technical terms as problems and for having no team settings.

For the plain-language case behind tools like this, see the guidance on writing for readers in Google's documentation. Good tools help, but the habit of short, clear sentences builds trust with readers on its own.

Planning a content calendar a small team can keep

Maren Okafor — Tue, 18 Aug 2026 00:00:00 +0000

A content calendar is a shared list of the posts you plan to publish, who writes each one, and when it is due. It sounds like admin. In practice it is the one tool that turns "we should blog more" into posts that actually go live, week after week.

Most small teams try a calendar once, fill it with twenty ideas, miss the first deadline and give up. This post shows a lighter way: a calendar small enough to keep, with time built in for the work nobody plans for.

Why most calendars fail by week three

The usual calendar is a wish list. It has a title for every Tuesday and no owner, no question and no time for editing. When one post slips, the whole plan slips with it, and the calendar becomes a record of what did not happen.

Our benchmark found that in 2026, 23% of the small business blogs we read used a content calendar shared with the whole team. The rest planned in someone's head or in a chat thread. Their median pace in 2026: 2 posts a month, with long gaps between bursts.

A calendar that survives has three traits. It is short, it names one owner per post, and it leaves gaps on purpose.

What a content calendar should hold

Keep the columns few. Every column you add is one more thing to update, and a calendar nobody updates is worse than none. These six are enough:

Column	What goes in it	Why it matters
Week	The week the post goes live	Sets the pace you can see at a glance
Working title	A plain title you can change later	Tells the team what the post is about
Question it answers	One sentence in the reader's words	Keeps the post focused on one job
Author	One name, never "the team"	Someone owns the deadline
Status	Idea, planned, drafting, editing or published	Shows where work is stuck
Refresh due	The season you will check it again	Keeps old posts from going stale

The question column does the most work. A post with a clear question is quicker to write and easier to edit, which is the core idea of our guide to SEO writing.

Pick a pace you can hold

Start slower than you think you need to. One good post a fortnight, kept up for a year, gives you a library of useful pages. Weekly posts that stop in the third month give you a few orphans and a guilty feeling.

A pace that lasts

One new post every second week. The weeks between are for editing, refreshing an old post and planning the next one. The calendar always has slack, so one late draft does not break it.

A pace that breaks

A new post every week with no slack. Editing gets squeezed, old posts never get touched, and the first holiday or sick day pushes every date back.

Fill the calendar from real questions

Do not brainstorm titles. Collect questions. Good sources are close at hand:

Sales and support. The questions customers ask before they buy and after they start.
The search bar. Type your main topic and read the suggestions and the questions on the results page.
Your own posts. Readers who finish one post often need the next step. That step is a post.

Write each question into the calendar as it comes, then pick the best ones when you plan the month. Before a post starts, turn its row into a short brief. Our members can use the content brief template we use for that.

Run the calendar in one short meeting

The calendar needs a rhythm, not a project manager. We use one fifteen-minute meeting a week:

Look at this week's row. Is the post on track? If not, move it now and say so.
Look at next week's row. Does the author have what they need?
Look at the refresh slot. Which old post gets attention this time?
Add any new questions to the bottom of the list.

That is the whole meeting. Anything bigger goes to a separate conversation.

What if a post is late?

Move it to the next free slot and tell the team in the meeting.
Never squeeze editing to keep a date. A late, edited post beats an on-time, rough one.
If the same post slips twice, the question may be too big. Split it into two posts.

Leave room for editing and refreshing

Every new post needs an edit before it goes live. Budget about half the writing time for it. We run each draft through the checklist our editors use, and that step belongs in the calendar as a date of its own, not as a hope.

Old posts need time too. Our benchmark shows that in 2026, 38% of the blogs had not updated a single post in twelve months. Yet posts updated within the year earned, in 2026, 1.6 times the search clicks of untouched ones at the median. A refresh slot every second week is a cheap way to collect that gain.

Check what the calendar produced

At the end of each quarter, look back. Which posts brought readers, sign-ups or sales? Which questions led nowhere? Move more of next quarter's slots toward what worked. Our post on measuring the return on content shows a simple way to do this without a data team.

Use our free template

We keep our own content calendar in a plain spreadsheet. You can download the same template and open it in any spreadsheet app. It has the six columns above and a few example rows to show the level of detail that works.

The Larkspur planning sheet, as a spreadsheet file

For a wider view of editorial planning, the Content Marketing Institute's planning resources cover calendars for larger teams.

Fact check: word count is not a ranking factor

Priya Raman — Tue, 11 Aug 2026 00:00:00 +0000

No. Google does not rank a post higher because it is long. Its own guide to helpful content says plainly that it has no preferred word count. Long posts often do rank well, but that is because they tend to answer more questions and earn more links, not because of the length itself.

The claim we checked

The claim turns up in briefs, agency pitches and tool reports. It usually reads like a rule: write a long post or do not bother. Some content tools score a draft by its word count against the pages that rank. Writers then pad a clear answer to hit the target.

We checked the claim in the form people make it: "Google ranks longer posts higher." That is a claim about cause. It says length itself moves a page up. To be true, a page would have to gain from the extra words alone, with nothing else changed.

What Google says about word count

Google publishes a guide to creating helpful, reliable, people-first content. It lists questions to ask of your own pages. One of them asks whether you write to a set word count because you heard Google prefers one. Right beside the question, Google answers that it does not.

The guide puts that question in a list of warning signs. They are the habits of content made for search engines first and people second. So Google does more than say length is neutral. It treats writing to a target length as a sign that the writer has lost sight of the reader.

The claim against the evidence

What people say	What the evidence shows
Google rewards long posts	Google's own guide says it has no preferred length
The top results are long, so length must help	The top results also cover more questions and earn more links
A longer post looks more expert	Expertise shows in detail, sources and a named author, not in bulk
Adding words to an old post lifts it	Padding pushes the answer down and makes it harder to find

The third row matters most for small teams. Google's idea of E-E-A-T (experience, expertise, authority and trust) is about who wrote a page and how they know. A real name, a first-hand example and a linked source show it. Extra words do not.

Why long posts often rank anyway

Sort the results for a broad query by length and long pages often sit near the top. The pattern is real. It just does not show cause. Three things tend to travel with length, and each of them can help a page on its own.

Wider coverage. A broad search hides many smaller questions. A guide that answers each of them matches more of what searchers want. The length is a side effect of the coverage.
More links. Thorough guides are the pages other sites cite, so they earn more backlinks. Links help a page be found and trusted. The words do not earn them; the usefulness does.
More care. Long guides are often a team's flagship pages. They get updated, linked from other posts and promoted. A short page with the same care would get much of the same lift.

Take those three away and the length alone has nothing left to give. A short page that answers a narrow question well will beat a long page that buries the same answer under a history lesson.

When two things rise together, ask what else is rising with them before you credit either one.

Priya Raman, research editor

What this means for your brief

Drop the target length from your briefs. Put a list of questions in its place. The post is done when it answers each of them clearly, once.

Start from the goal behind the search. Someone who asks how long a meta description should be wants a number and a reason, then wants to leave. Our meta description guide answers in two lines and stays short on purpose. Someone who asks how to plan a year of content wants a method, and that post will run long because the method has many parts.

Our full guide to writing posts that rank walks through the whole process, from the question to the final edit.

How to judge the right length

You can find the right length without counting a single word.

Read the results page. If the pages that rank all answer in a few lines, a long post will not beat them.
List the questions. Write down each question a reader will have, in the order they will have it.
Answer each one once. No section should say again what another already said.
Cut what does not serve. Our checklist for the second draft shows where padding hides.
Read it on a phone. A buried answer is easy to spot on a small screen.

How this page is marked up

This page carries structured data for a fact check, known as ClaimReview: a short block of code that names the claim, our rating and who rated it. Fact-check tools can read the verdict without guessing. Khalid writes it from the post's settings, so the page and the code always agree.

How we check claims

Every fact check follows our editorial policy. We write the claim the way people make it, then look for the source best placed to know: the search engine's own documents, a standard, or a test we can repeat. We rate the claim on a five-point scale, from one for false up to five for true, and we give the verdict in words as well. A second editor reviews the evidence before we publish. If new evidence changes the verdict, we update the page and add a dated note that says what changed.