What the ANA and NewtonX finance survey and Bain and Google’s study of 1,397 executives say about the vocabulary problem between marketing and finance

Marketing teams went into 2026 planning season with more dashboards than ever.

Finance teams went in with a different question: which of these numbers can we actually plan around?

Two studies published this year put figures on that gap. One asked finance leaders directly how much they trust marketing’s measurement. The other asked both sides what they want from each other. Read together, they point to a problem that has less to do with budgets or priorities and more to do with words.

We pulled the findings together because they shape how every B2B marketing channel gets judged in 2027, including content syndication, which is the channel we work in.

Study one: the ANA and NewtonX finance survey

The ANA’s Confident B2B Marketer report has surveyed marketing leaders before. The 2026 edition added something new.

NewtonX fielded the survey in April 2026 to 202 senior B2B marketing leaders at director level and above. It also surveyed 150 CFOs, VPs of finance and heads of revenue. On top of that, the team ran 23 AI-moderated interviews with high-confidence marketers and 8 longer interviews with senior finance executives.

The headline numbers form a staircase.

59% of marketers said they can measure marketing’s financial impact.

45% of finance leaders agreed that marketing can do that.

37% of finance leaders said marketing’s impact had been reliable enough to use for planning and forecasting.

12% said that measurement holds up under pressure.

Each step down is a harder test. Measuring something is one bar. Forecasting with it is a higher one. Defending it when a CEO or board member pushes back is the highest, and very few marketing numbers clear it in finance’s eyes.

The interviews with finance executives added a useful detail. Trust erodes in specific moments: during planning cycles, under scrutiny, and when budgets get tight. It rarely disappears all at once.

The Vocabulary Gap

The report gives the main cause a name. It calls it the Vocabulary Gap, meaning the absence of shared definitions for pipeline, attribution and impact.

When marketing, sales and finance each define pipeline differently, the same quarter can get three different verdicts. The report lists what follows from that: AI outputs get questioned, data integrations fragment, brand investment gets cut, internal champions lose debates and forecasts miss.

The authors call closing this gap the most immediate and highest-leverage move most B2B marketing leaders can make.

That is a useful framing because it is fixable without new software. It takes a meeting and a written agreement.

Study two: Bain and Google on proof of performance

Bain and Google’s Leaders and Laggards Survey 2026 covered 1,397 senior marketing and finance executives around the world. Bain published the findings on July 2, 2026.

Its main finding is that marketing and finance largely agree on what matters.

Both groups named return on marketing investment and revenue impact as their top success measures.

More than half of each group said that showing direct revenue impact is the single most important thing marketing can do to strengthen its standing with finance.

About 70% of each group expect performance investments to pay back within months or quarters. About 40% expect brand investments to take a year or more.

So the two functions share goals and even share timelines. Where they split is on proof.

Only 41% of marketers said they feel properly equipped with the data, tools and measurement capabilities to tie performance to business outcomes. Only 19% described their AI capabilities for analytics and insights as mature.

What the strong relationships look like

Bain split companies by how well their marketing and finance teams work together. 501 respondents described a strong relationship and 138 described a weak one.

Companies with strong relationships were 2.5 times more likely to have credible data.

They were also about 1.5 times more likely to be market share and revenue growth leaders in their sectors. Bain’s text describes the revenue link as almost two times higher growth.

The habits Bain describes in those companies are concrete:

• They lock metrics before campaigns launch, so nobody redefines success after the results come in.
• They share failures alongside successes, which Bain calls radical transparency in data.
• They set shared, realistic payback expectations, especially for brand campaigns that take longer to show up in revenue.

None of these habits depends on a particular tool. They depend on agreeing on terms early and reporting honestly afterward.

Putting the two studies side by side

The ANA and NewtonX data shows the symptom: finance trust drops sharply as the stakes rise.

The Bain data shows that the goals are shared, so the trust gap is about evidence and definitions.

Both reports land on the same first fix. Write down what pipeline, an opportunity and attribution mean before the money is spent, and get finance to sign off on those definitions.

A cohort approach that holds up

Our research on proving syndication ROI to a CFO builds on these findings. The core idea is to stop reporting a running total and start reporting cohorts.

A cohort is every lead delivered in one month, followed as a group from delivery to closed-won revenue.

The ROI formula for each cohort is simple. Take closed-won revenue, subtract program spend, then divide by spend. You run it for each delivery month separately, and you keep the cohort open until the payback window you agreed on with finance has ended.

Timing matters here. SQLs from a syndication cohort usually appear within weeks of delivery. Opportunities and revenue arrive over the following months, at a pace set by your sales cycle. Setting the payback window to match that cycle is what keeps a CFO from judging a cohort before it has had time to convert.

This also lines up with the Bain payback finding. If 70% of finance leaders expect performance spend to pay back within months or quarters, a cohort report with an agreed window speaks their language.

Why lead-level records help with the Vocabulary Gap

One reason we think syndication is a good test case is the record each lead carries.

A syndicated lead arrives with contact details, the specific asset the person downloaded, a timestamp and the answers to qualifying questions. Those fields can be matched against CRM records.

That gives marketing and finance something concrete to define terms around. An accepted lead, an SQL and an opportunity can each be tied to a named record with a date, which is much easier to audit than a modeled share of a multi-touch path.

Questions to settle with finance before your next program

Based on both studies, these are the questions we would bring to a planning meeting with finance:

1. What counts as pipeline, and at which stage does marketing stop getting credit?
2. What payback window fits our actual sales cycle?
3. Which cost do we report: total spend, or spend on accepted leads only?
4. How will we report a cohort that misses?
5. When results come in, whose conversion rates do we re-forecast with: vendor benchmarks or our own?

The last two questions get skipped most often. Bain’s leaders answer them in advance, before any results exist to argue over.

The full research on proving content syndication ROI, including a scorecard and a worked pilot example, is here: https://lead-spot.net/research/how-to-prove-content-syndication-roi-to-your-cfo/

Sources

• ANA and NewtonX, Confident B2B Marketer 2026
• Bain and Company, The Marketing-Finance Divide Is About Proof of Performance, Not Priorities (July 2, 2026)
• LeadSpot, How to Prove Content Syndication ROI to Your CFO

Most teams find out how their docs review works on a bad day.

A customer follows a guide and something breaks. Someone asks who approved that page. The answer takes an hour of scrolling through pull requests, and it ends with “I think it was reviewed.”

We would rather find that out on a quiet afternoon, with fake content, in a repository nobody depends on.

This piece is a practical drill for doing that. It is based on a research report we published at Docsio on review controls in GitHub and GitLab. The report proposes the scenarios below. It does not claim anyone has run them, and neither do we. Think of this as a plan you can try.

Before you start: write the policy in one paragraph

The drill only works if you know what you are testing against.

Write down, in plain words, what review a docs change needs before it reaches readers. Who has to approve which kinds of pages. What happens if the page changes after approval. Which routes are allowed to publish.

Keep it short. One paragraph is plenty for a small team.

If you cannot write that paragraph, that is your first finding. The tools can only enforce a policy someone decided on.

Set up a disposable repository

Create a throwaway repo that mirrors how your real docs repo is configured. Same plan, same visibility, same branch rules, same owner file, same deploy workflow pointed at a test destination.

Use fictional content. A made-up setup guide and a made-up troubleshooting page are enough.

Then write down four facts before you begin: your plan or tier, whether the repo is public or private, which rule type you are using, and today’s date. Platform behavior differs across tiers and between hosted and self-managed versions, so a result without those details is hard to trust later.

Meet Northstar Guides

The report uses a fictional team to make the drill concrete. We will borrow it.

At Northstar Guides, support owns troubleshooting prose. Engineering owns commands and code samples.

That split creates a real question. When a troubleshooting page includes a command, does one approval cover both? Or does the page need a yes from support for the words and a yes from engineering for the command?

There is no universal answer. The point is that Northstar has to decide, and then check that its configuration does what it decided.

Your team probably has a version of this split. Marketing owns the pricing FAQ and finance owns the numbers. Product owns the onboarding guide and security owns the SSO steps. Name yours before you run the drill.

The eight scenarios

Run each one with a fictional change. For each, write down what you expected, what happened, and which account you used.

1. Edit a guide nested a few folders deep. Does the right owner get requested, and is their approval required to merge?
2. Add a brand new section that no existing owner rule covers. Who gets asked? Can it merge with no owner approval at all?
3. Get a change approved, then edit an instruction in it. Does the approval stay, go away, or partly go away?
4. Repeat a change using an ordinary contributor account instead of an admin. Admin accounts often bypass rules by default, so they make results look stricter than they are.
5. Make a change using the identity your release process runs as. What can that identity do without a person approving it?
6. Try to run a test release before the change is approved. Does anything stop it?
7. Compare the record from a preview build with the record from the real release. Do they point at the same revision?
8. Change the ownership configuration itself. Who can do that, and does anyone have to approve it?

Scenario 8 is the one teams skip most often. If the person who approves content can also quietly edit who approves content, the rest of the drill matters less.

How to record what you find

Some results will surprise you. The report gives a useful way to describe them.

If something publishes without the review your policy expected, and it happened through a route your team allows, call it an exception to review enforcement. A documented hotfix path is a good example. It is a gap in your policy coverage, and it may be a perfectly reasonable one.

Avoid calling it a platform failure unless the platform did something different from its own documentation.

And for any route you did not test, write “unknown.” A hosting dashboard you forgot about, a manual upload, a script from launch week. An honest list of unknowns is more useful than a clean report that skips them.

Keep a six-line release record

After the drill, most teams want something ongoing. The report proposes a short record that links reviewed content to the published result. It has six entries.

• Content candidate: the revision or a draft identifier that will not change.
• Review decision: who reviewed it, what scope they covered, when, and which candidate they saw.
• Effective policy: the rules that applied, plus any exception someone made on purpose.
• Validation: check results, the revision they ran on, and the preview if one matters.
• Release: the deployed revision or artifact, and where it went.
• Follow-up: any correction, withdrawal or replacement afterwards.

You do not need a new tool for this. Each entry can link to a system you already have, like a pull request, a CI run or a deploy log.

One detail matters a lot. Use stable references, like a commit or artifact identifier. Branch names move. “Main” on Tuesday is a different thing from “main” on Friday.

The record has limits worth stating. It shows who approved which revision. It cannot show that the content is accurate, and it cannot show that nothing unauthorized happened outside the routes it tracks.

Scale review to what the change can break

A drill like this can push teams toward reviewing everything heavily. The report pushes back on that, and we agree.

A factual change to an authentication guide deserves more care than fixing a typo in a footer. Your policy can say so.

The report also suggests defining the smallest useful review package. That means the changed material, the source that supports it, who the page is for, and a preview when layout changes the meaning. A table that collapses on mobile, for example, or a code block that wraps badly.

If reviewers get that package every time, reviews get faster without getting weaker.

AI-drafted pages follow the same rules

More docs teams now start pages with an AI draft. The report’s position is simple. AI-drafted text should meet the same evidence expectations as anything a person wrote.

Fluent writing can make a page feel already reviewed. It still needs the same approval on the same revision that ships.

Leave room for emergencies

The last piece of the drill is deciding how urgent fixes work.

If a page tells customers to run the wrong command, you want it fixed in minutes. So keep an emergency route. Just record three things each time it is used: who authorized it, what was published, and what follow-up is still open.

That turns the side door into a known door.

What you will have at the end

After one afternoon, you should have a one-paragraph policy, eight results with the accounts you used, a list of exceptions, a list of unknowns, and a release record format your team can start using on the next change.

That is a lot more than “I think it was reviewed.”

The full research behind this drill, including the GitHub and GitLab details for each control, is on the Docsio research page: https://docsio.co/research/docs-as-code-review-enforcement

Docsio builds branded docs sites from a website URL in about 30 seconds. You can try it at Docsio.co.

Someone on your team spends a week sorting out how your versioned docs show up in Google.

They decide which releases stay searchable, which duplicate addresses get consolidated, and what happens to the retired release. They ship the settings. Everyone moves on.

Three months later, a support ticket arrives from a customer on an older release. They followed the setup guide from Google and it described a screen they don’t have.

Was the policy wrong? Did the site ignore it? Did Google pick something else? Without a record, nobody can say.

Our team at Docsio published a research report on versioned documentation and search indexing. Most of it covers how to make the decisions. This piece covers the part after: checking what actually happened. The report proposes the method. It wasn’t run as an experiment, and no traffic was measured. I’ll walk through it with the report’s made-up product, Atlas.

Meet Atlas

Atlas has four kinds of documentation:

• Release 4: current
• Release 3: older, still supported
• Release 2: retired, kept as a reference
• Release 5: a private preview

There’s also a duplicate domain alias that serves the same pages at a second address.

The report gives Atlas a starting set of decisions. Each one begins with what a reader needs and ends with a question you can check.

1. Release 4 current guides. Readers want to learn the current product. Keep them eligible for indexing. Check: do pages identify release 4 and serve release 4 instructions?
2. Release 3 guides that changed. Readers run a supported older installation. Keep the distinct guides eligible. Check: can a release 3 reader stay in release 3?
3. The duplicate domain alias. Readers get the same page at another address. Prefer the primary address. Check: do both addresses really carry the same content?
4. The release 2 archive. Readers follow a retained historical reference. Keep it public, and exclude it from Google if your support policy calls for it. Check: does the archive open without implying it’s current?
5. The release 5 preview. Reviewers read unpublished instructions. Use access control. Check: is access denied without permission?

Those checks are what the audit tests. Before anything ships, the report suggests three sign-offs: the product owner confirms which releases are supported, the docs owner confirms which pages are true duplicates, and whoever owns search maps each decision to a control.

The six-step audit

Step 1: Freeze the policy record

Write down the decisions for the release under review, and keep that record separate from anything you observe later.

This sounds like paperwork. It’s the step that stops a team from quietly rewriting the policy to match whatever Google did. The report also warns against changing the policy while you’re still waiting for results.

Step 2: Pick representative pages

Choose pages for each policy case. For Atlas, that means at least a current release 4 guide, a changed release 3 guide, an unchanged page that exists in both releases, and an archive page from release 2.

Include a deep page, several clicks from the homepage, and the same page on the alias domain. Write down why you chose each one.

Step 3: Inspect the live output

Open each page as it’s actually served. Record the status code, where any redirect lands, which release’s content appears, the indexing rule, the canonical tag, the crawler rule that applies to the path, and whether the page is in the sitemap.

The point is to look at the delivered page instead of the settings screen. Hosts generate a lot of this automatically, and a theme or custom build can change the result.

Step 4: Save the time and the deployed revision

Note when you looked and which build was live.

Without this, you’ll eventually compare a Search Console report against a build nobody can identify. The report calls this comparing results against an unknown build.

Step 5: Read what Google indexed

In Search Console, look up each page’s last crawl date and the canonical Google selected.

Keep the live URL Inspection test separate. The live test tells you whether Google can fetch the page right now. It can’t predict which canonical Google will choose. The indexed data is where that choice shows up.

Also remember that being in a sitemap doesn’t mean a page was indexed.

Step 6: Classify every mismatch

When the indexed result differs from the policy, sort it into one of four buckets:

1. Site output problem: the page is serving the wrong tag, rule or content.
2. Policy disagreement: the page is doing what you asked, and Google chose differently.
3. Outdated observation: Google hasn’t recrawled since the change.
4. Unresolved indexing outcome: you can’t tell yet.

Each bucket points to a different next step. A site output problem goes to whoever owns the build. An outdated observation mostly needs patience. Lumping them together is how teams end up fixing the wrong thing.

What to measure afterward

The report separates three kinds of observation. They’re easy to blur, and each answers a different question.

Technical observations

These cover what the site delivered and what Google reported. For Atlas, a good one is whether the changed release 3 setup guide’s Google-selected canonical is itself. If Google folded it into release 4, release 3 readers will have a hard time finding it.

Discovery observations

Impressions, clicks and version-specific queries, over a stated period.

Context matters here. If the release 2 archive loses impressions after you deliberately excluded it, that’s the expected result. If a supported release 3 guide loses the same impressions, something needs investigating.

The report flags two quirks. Search Console credits most performance data to the canonical URL, so traffic for a duplicate may show up under a different page. It also leaves out some queries. Read the numbers with both in mind.

Reader observations

This is the one teams tend to skip.

Give a reviewer a release and a task, and see where they end up. For Atlas, the report suggests three tasks: configure release 3, install release 4, and find the retained release 2 reference. The reviewer records which version they reached and why.

It’s a task check with a few people, and it won’t estimate anything about your whole audience. It does answer the question the policy was written for. Total clicks can’t stand in for it.

What this method won’t tell you

The report is careful about scope, and so should you be.

It covers Google and Read the Docs only. Other search engines may treat these rules differently. No source it reviewed sets a universal number of versions to index, a guaranteed recrawl timeline, or an expected traffic gain.

A handful of representative pages shows you whether each policy case works. It doesn’t estimate how many pages across the site are wrong.

What you get is a record. When that support ticket arrives three months later, you can look up what you decided, what the page served, and what Google chose, and work out which part went wrong.

We build docs sites at Docsio, and versioned docs come up constantly. If you’re about to change how yours are indexed, start the record before you change the settings.

The full report, with sources from Google Search Central, Search Console Help and Read the Docs, is at docsio.co/research.

Source: Which versions of your documentation should Google index?

By July 1, 2026, 322,292 Californians had filled out a form asking to be erased.

Each request went to every registered data broker in the state, nearly 600 of them by the count GovTech reported, asking each one to delete what it held on them and to stop collecting more.

The platform they used is DROP, the Delete Request and Opt-out Platform run by CalPrivacy. Most of the coverage so far has been about compliance: deadlines, penalties, registration. We wrote about that side in our own research.

This piece is about the people. When a few hundred thousand people take time out of their day to ask for less contact, we think marketers should treat it as a signal about their audience.

What signing up takes

According to CalPrivacy’s executive director, Tom Kemp, signing up takes about six to seven minutes.

A resident verifies that they live in California, either by entering basic personal details or by signing in through Login.gov. Then they build a profile and choose what to include: names, birth dates, ZIP codes, email addresses, phone numbers, even vehicle identification numbers.

The more they add, the more brokers can match. Kemp described the required information as the “bare minimum” needed to find people in broker records. The agency doesn’t ask for Social Security numbers, driver’s license numbers or credit card numbers.

So every one of those 322,292 people decided that six or seven minutes, plus handing over their own email and phone number, was worth it to be found less often.

What they said they wanted

GovTech’s reporting didn’t include a survey of individual motives. What it did include was how the agency describes the benefits, and those line up closely with complaints any B2B buyer would recognize.

Kemp said people who sign up should see fewer ads based on their demographics. He said they should see fewer text scams, less email spam and less junk mail. He called the whole thing “an investment” in making yourself more secure.

He also put the problem simply: “Our data is their product, and they don’t sell it back to us.”

That sentence is worth sitting with if your pipeline depends on someone else’s contact database. The person on the other end of a cold email is usually a person who never chose to be on the list.

Who sells what

The registry gives a rough picture of what brokers trade in. GovTech’s breakdown of the nearly 600 registered brokers included these figures:

• 110 sell precise location data
• More than 40 sell identity data that can include Social Security numbers
• 18 sell data about minors
• About 30 sell to developers of generative AI
• More than 20 sell to foreign entities

Kemp also said there are “clearly more than 600” brokers operating once you count the ones that haven’t registered, and the agency’s enforcement team is investigating reports of those.

Most B2B marketers will never touch a location feed. But the same registry includes the companies that sell names, work emails and direct dials, and DROP doesn’t sort brokers by how harmless their product feels.

Why the number keeps climbing

There are two reasons we expect the 322,292 figure to grow.

The first is that sign-ups are permanent. Once someone registers, brokers have to keep honoring the request and screen new records against it before selling them. Nobody ages out of the list.

The second is visibility. Brokers began processing deletions on August 1, 2026. Per the agency, people in the first round should have started seeing results in late October. Kemp said he expects sign-ups to grow as purges happen and word spreads.

There is plenty of room. More than 30 million Californians haven’t signed up yet, and Kemp believes many of them simply don’t know the program exists.

Enforcement adds pressure on the broker side. GovTech reported that brokers who failed to register have settled for $35,000 to $55,000, and that DataMasters of Texas agreed to a $45,000 fine and was ordered to stop selling Californians’ data. Kemp said the fines appear to be pushing more brokers to register, and that the agency is prepared to pursue fines in the “tens of millions of dollars.”

What we take from it as marketers

Under 1% of the state has signed up. On its own, that won’t empty anyone’s CRM this quarter.

What stands out to us is the direction. Every month the list gets a little longer, nobody leaves it, and the people on it are the ones most annoyed by contact they didn’t ask for. Those are often the same senior, busy, frequently contacted buyers B2B teams want most.

A few things follow from that.

Ask before you reach out. A buyer who gives you an email address in exchange for something they wanted is in a different position from a buyer whose email you rented. California’s own guidance treats information a person knowingly shares with a business differently from information a broker collects and sells. Opt-in channels, from your own forms to content syndication, line up with how people are telling regulators they want to be treated.

Give them a reason that is about them. The motives Kemp described were about spam, scams and irrelevant ads. A research report, a benchmark or a useful tool gives a buyer a reason to raise their hand. That trade is easy to understand and easy to honor.

Make leaving easy too. If people will spend seven minutes on a government form to stop being contacted, a one-click unsubscribe that works within days costs you very little and earns some trust.

Expect quieter regions. As DROP grows, purchased California coverage will thin out in ways that won’t show up as bounces. The contact still has the job. They just stop showing up in the data you can buy.

The part nobody can buy

We sell lead generation, so we have an obvious interest here. Our programs are built on buyers who fill out a form to get a specific piece of content, and we think that model fits where privacy rules are heading.

But the bigger point stands without us. Hundreds of thousands of people have now told the state, in writing, that they want fewer strangers holding their contact details. The companies that keep reaching those people will be the ones the buyers chose to hear from.

That permission is the one data asset DROP can’t delete.

Sources: GovTech, “Why 300K Californians Signed Up to Have Personal Info Removed” (July 2026); CalPrivacy DROP overview. This article isn’t legal advice.

A new number has started showing up in SEO tools and agency reports.

It usually looks something like this: “Your page covers 6 of 10 fan-out queries.” Or “Fan-out coverage: 60%.”

If you run a small business, that number can feel like a grade. Sixty percent sounds like a D. You start wondering what you missed and how fast you can fix it.

Before you rewrite anything, it helps to know where that number comes from and what it can and cannot tell you.

We spent time with the public documentation from Google, OpenAI and Perplexity, plus the largest public study on the topic from Ahrefs. This piece takes what we learned and applies it to one practical question: what should a small business owner do when a tool hands them a coverage score?

First, what fan-out means

When someone asks an AI search tool a question, the tool may split it into several smaller searches before it answers.

Google’s documentation says AI Overviews and AI Mode may run “multiple related searches across subtopics and data sources” to build a response. That is query fan-out.

The word “may” matters. Google describes something its systems can do. It does not publish a list of the searches it ran for any particular question.

OpenAI’s developer docs say its web search tool usually returns the queries it searched, but not always. Perplexity’s developer docs show example records of queries and results.

So some fan-out searches can be seen, some of the time, through developer tools. Most everyday users never see them at all.

Keep that in mind, because it shapes everything about a coverage score.

Meet Two Rivers Bread Co.

To make this concrete, we will use a fictional business.

Two Rivers Bread Co. is a small bakery in Lancaster, Pennsylvania. The owner, Dana, sells sourdough loaves at the counter and runs a weekend sourdough starter class for about a dozen people at a time.

Dana wrote a page called “How to keep a sourdough starter alive.” It gets steady Google traffic. She wants it to show up when someone asks ChatGPT or Google AI Mode for help with a sluggish starter.

She runs the page through a tool. The tool reports:

“Fan-out coverage: 6 of 10 queries (60%).”

It lists the four “missing” queries:

1. Can I use tap water for sourdough starter?
2. Why does my starter smell like nail polish remover?
3. Best flour for sourdough starter
4. Sourdough starter vs commercial yeast

Dana’s first instinct is to add four new sections to the page. Here is what we would ask first.

Question 1: Where did these ten queries come from?

This is the most important question, and many reports do not answer it on the screen.

There are a few ways a tool can produce a list like this:

• Returned by an interface. The tool sent a question to an AI system through a developer API, and the API returned the searches it ran.
• Observed in sessions. The tool collected real responses and pulled out the searches recorded in them.
• Generated by a model. The tool asked an AI model to guess what related questions someone might search.

These are very different things.

A query returned by an interface tells you that one system ran that search for one request, at one point in time.

A model-generated list is a set of reasonable guesses. It can be useful for brainstorming. It tells you nothing about what Google, ChatGPT or Perplexity actually searched.

If Dana’s tool generated its ten queries with a model, then “6 of 10” means her page answers six of the tool’s own suggestions. That is a fine starting point for editing. It is not a measurement of her visibility.

Ask the vendor for one sample export that shows where each query came from. If they cannot show you, treat the list as brainstorming.

Question 2: What is the denominator?

The denominator is the bottom number in the fraction. In “6 of 10,” it is the 10.

The percentage only means something if you know what the 10 represents and why those ten were chosen.

Some things worth asking:

• Which AI product was sampled? ChatGPT, Google AI Mode and Perplexity behave differently.
• Were the sessions logged in or logged out? Free or paid?
• How many times was each question asked?
• Was the list fixed before the page was checked, or adjusted afterward?

That last point is easy to miss. If a list can be swapped out after the fact, the score can rise just because harder questions were dropped.

Ahrefs offers a good example of why sampling details matter. Its October 2026 study looked at 66.6 million responses from free, logged-out sessions of GPT-5.6 Luna in August and September 2026. It found fan-out queries in 14.4% of those responses.

Ahrefs notes that free, logged-out sessions search less than paid or reasoning models. It also used broad prompts, rather than the “best X near me” style prompts that buyers type. And Ahrefs later corrected its own wording, from “14.4% searched the web” to “14.4% contained fan-out queries.”

That is one careful study being clear about its limits. A coverage score in a dashboard deserves the same level of detail.

Question 3: What does “covered” mean?

A tool might mark a query as covered if the page contains certain words. Another might use a model to judge whether the page “answers” the question.

Neither tells you whether a reader with that question would walk away satisfied.

There is also a second gap. Even if the queries are real, OpenAI’s documentation separates sources a model consulted from sources it cited in the answer. A page can be read and still not be cited. A coverage score usually cannot tell you which of those happened.

And nothing in the public record we reviewed shows that raising a coverage score leads to more AI citations. Google’s own AI features guidance says there are no special optimizations needed to appear in AI Overviews or AI Mode beyond normal search basics.

What Dana should do instead

The score is not useless. It handed Dana four questions worth thinking about. The trick is to treat them as questions to review, one at a time, instead of gaps to fill.

Here is how we would walk through her list.

Tap water. This is a real problem for people keeping a starter alive. Chlorinated water can slow some starters down. Dana answers this question at her class almost every weekend. It belongs on the page, in a short section near the feeding instructions.

Nail polish smell. This is a classic sign of a hungry starter. Someone searching it is in the middle of the exact task the page covers. Dana adds two sentences and a note on how to fix it.

Best flour. This one is bigger than it looks. A real answer involves protein content, whole grain versus white, and what local mills sell. That could swamp the page. Dana writes a short line on the page and plans a separate article about flour, linked from the original.

Starter vs commercial yeast. People asking this are deciding whether to start sourdough at all. Dana’s page is for people who already have a starter. This question serves a different reader, so it does not go on this page.

After her edits, the tool might say 8 of 10, or it might say something else. Dana does not need to care much either way.

What matters is that someone with a struggling starter can now solve their problem on her page, and that she can point to her own class experience as the source for her answers.

A short checklist before you trust any coverage score

• Ask where every query came from: returned by an interface, observed, or generated.
• Ask which AI product, account type and date range the queries came from.
• Ask whether the list was fixed before your page was checked.
• Ask how the tool decides that a query is “covered.”
• Read each missing question yourself and decide whether your reader needs it on this page.
• Keep a copy of the page before and after your edit, with the date, so you can compare later.

If a vendor cannot explain the source and the denominator, set the number aside and read the questions.

Where this leaves small businesses

Fan-out is real. Google documents it, OpenAI and Perplexity expose parts of it to developers, and Ahrefs measured it in a large sample from one model.

What no public source shows is a reliable way for an outside tool to see every search an AI system runs for your customers, or a proven link between covering those searches and getting cited.

For a bakery owner, a plumber or a solo consultant, that is good news in a way. You do not need a perfect score. You need pages that fully answer the questions your customers actually bring to you, written from the experience only you have.

We wrote up the full source review on the outwrite.ai research page, including all seven documents we inspected.

Sources

• Google Search Central, AI features and your website
• OpenAI, Web search
• Perplexity, Agent API quickstart
• Ahrefs, How ChatGPT Does Query Fan-Out (October 12, 2026)
• outwrite.ai, Query Fan-Out: What You Can Actually Observe

Two Rivers Bread Co. is a fictional business used for illustration.

Ask a team how their localized docs are doing and you’ll usually get a percentage.

“French is at 80%.”

That number almost always means pages. Eighty of a hundred pages have a French version. It’s easy to count, and it goes up every time someone publishes something.

It also tells you very little about whether a French-speaking customer can set up your product.

We looked at this question in a new Docsio Research report on translated documentation. This piece pulls out the measurement side of it: what to count, how to count it, and how to check a release before readers find the gaps for you.

Start with tasks

A reader rarely arrives wanting “page 47.” They arrive wanting to connect an account, rotate an API key, or invite a teammate.

So the first step is a short list of essential tasks. These are the jobs a new or paying customer has to be able to finish without contacting you. Keep it short enough that someone can name every item from memory.

Then, for each language, you ask one question per task: has a person reviewed the translated version of this task against the current source, for the release customers are on?

Here’s the illustrative example from the report. A docs site has 100 pages. Eighty have French versions, so page coverage is 80%. The site has 10 essential tasks. Six have reviewed French versions, so task coverage is 60%.

The gap between 80 and 60 is where readers get stuck. Those four unreviewed tasks might be your most visited pages.

The report makes one recommendation about this that we’d underline: keep the two denominators separate. If they get blended into one score, the dashboard starts rewarding teams for publishing unverified pages.

Five measures worth tracking

Task coverage is the first of five measures the report proposes. Each one answers a different question.

1. Reviewed task coverage. Named tasks reviewed for the release that matters. Use it to decide which customer paths to translate or review next.
2. Consequential changes awaiting review. Source changes that affect what a reader does, grouped by how serious the effect is. Use it to decide when a correction should interrupt routine work.
3. Review lag. Time from a source change to its review, split by severity. A typo can wait a week. A new required permission probably can’t. This measure shows whether you’re meeting your own targets.
4. Fallback use. How often a reader was offered another language because a translation was missing or suspended, and how often they took it. It shows where readers hit gaps. A click on the fallback doesn’t prove the fallback worked, so treat it as a signal.
5. Observed task completion. Whether real people finish a task, recorded with their language ability, the task, the release and what counted as success. This is the slowest to collect and the most direct evidence you’ll get.

None of these require special tooling to start. A spreadsheet with one row per task per language gets you the first three.

A worked example: the connection guide

The report uses a fictional analytics product with a guide called “Connect your reporting account.” It’s a useful case because the change looks small.

The English source moves from revision A to revision B. Revision B adds one prerequisite: a workspace owner now has to approve the connection. It also changes the confirmation screen.

The French translation was reviewed against revision A. It still says any member can complete the connection.

Walk through what each measure shows on the day revision B ships.

Page coverage doesn’t move. The French page still exists, so it still counts.

Task coverage drops by one. “Connect your reporting account” no longer has a French version reviewed against the current source.

Consequential changes awaiting review goes up by one, and it’s classed as serious. A missing prerequisite means some readers will fail.

Review lag starts counting from the moment revision B was published.

Fallback use and observed completion will tell you, over the next few days, how many French readers are hitting the problem.

If the dashboard only showed page coverage, everything would look fine. Members without owner rights would be getting an unexplained failure the whole time.

The report suggests two acceptable responses. The better one is a reviewed French correction that adds the prerequisite and updates the screen reference. If that can’t happen quickly, remove the misleading claim and offer the current English guide, with a clear note about what language it’s in.

Sorting changes by effect

The review queue only works if changes are classified by what they do to the reader. The report’s scale runs from a typo, which changes nothing about the action, up to a new warning on a destructive step, where the outdated instructions should be suspended.

When someone publishes a source change, they should record which of those it is. That one field drives the queue, the lag measure and whether readers need a notice.

A release check you can copy

The report closes with a release check. Here’s our condensed version for a small team.

Before publishing a source change

• List the translated tasks it affects.
• Give each affected task an owner.
• Record whether the change alters actions, prerequisites, examples, screenshots, or only wording.

Before publishing a translation

• Check it in the real page layout. Look for wrapped button labels and tables that no longer fit.
• Copy every command and run it. Translation tools sometimes swap straight quotes for typographic ones or change punctuation inside code.
• Confirm product labels, links and expected outputs match the release.
• For right-to-left languages, have a target-language reviewer check mixed-direction text like file paths and identifiers.

Accessibility

• Status is conveyed in text, not just color.
• Notices sit before the instruction they affect.
• Language controls work with a keyboard.

Reader routes to test

• A shared URL opened cold
• A search result that lands halfway down the page
• Switching language while viewing an older release
• Choosing a language that has no current page for this task
• The status notice on a narrow phone screen

Closing the change

• Mark it done only when the public page matches the review record.
• When a translation is restored, remove the temporary notice and test the fallback routes again.

What this doesn’t prove

The five measures and the release check are proposals. The report says plainly that they haven’t been validated across languages or products, and the 80/60 figures are illustrative.

What they do give you is a way to see the problem the page count hides. That’s usually enough to change what the team works on next week.

If you don’t have a docs site yet, you can paste your product’s URL at docsio.co and have a branded one to work from in about 30 seconds. Then write your task list before your first translation.

The full report, with sources from Kubernetes, MDN, the W3C and Google Search Central, is here: https://docsio.co/research/translated-documentation-freshness

Almost every credit union in the U.S. now works with outside technology partners.

That part of the story is settled. What is less talked about is how often those partnerships take longer than anyone planned, and how that delay shapes the way fintechs should market to credit unions in the first place.

We spend a lot of time running lead programs for fintech and payments companies. The question we hear most from their marketing teams is some version of “why is this taking so long?” A credit union downloads a guide, shows real interest, and then the deal sits for months.

The 2026 research from PYMNTS Intelligence and Velera gives a pretty direct answer. Here is what it says, and what we think it means for fintech marketing.

Partnerships are now the default for credit unions

PYMNTS and Velera publish a recurring study called the Credit Union Innovation Readiness Index. In the edition covered by PYMNTS on March 5, 2026, only 0.6% of credit unions said they could fully innovate without outside support.

Roughly 9 in 10 credit unions collaborate with at least one external partner. The types of partners break down like this:

• CUSOs and cooperative networks: 51.8%
• Fintech or technology providers: 47.2%
• Core or digital banking providers: 39.2%

Size matters a lot here. Only 12% of credit unions under $500 million in assets build bespoke innovations themselves. Among the largest credit unions, that share is 63%.

For a fintech, that split is useful to know. Smaller credit unions lean heavily on partners because they lack the internal teams to build. Larger ones have more options and more internal opinions to manage.

Most projects take longer than planned

This is the number that stood out to us. In the same index, 77% of credit unions said their most recent innovation took longer than planned.

The fintechs in the study tell a matching story:

• 22% said their projects met the planned timeline
• 0% finished ahead of schedule
• 12% reported significant delays, rising to 25% among the largest fintech providers

Zero percent finished early. If you sell to credit unions, it is safe to plan for your project running long.

The delay also shows up in expectations. Among credit unions the study calls “Laggards,” 57% expect projects to last one to two years, and 28% expect more than two years.

Return on investment depends on who you sell to

The index sorts credit unions into groups based on how they approach innovation. “Early Launchers” move quickly. “Laggards” move slowly.

The ROI gap between them is wide:

• 30.8% of Early Launchers say they fully achieved ROI from their latest project
• 6.3% of Laggards say the same
• 21.9% of Laggards have not achieved ROI yet, compared with 15.4% of Early Launchers

Fintechs see it from their side too. Only 16% report fully achieving ROI on credit union projects, while 72% say ROI is partially achieved.

When most projects end up “partially” successful, the credit union’s next buying decision gets more cautious. That caution carries into every new vendor conversation.

Where the friction comes from

Both sides in the study were asked what gets in the way.

Fintechs pointed at the credit union. 88% cited credit union decision-making complexity, and 82% cited legacy system constraints.

Credit unions pointed back. 92.9% cited partner limitations around technical or regulatory flexibility, and 77.2% cited communication delays.

A separate PYMNTS piece from March 31, 2026, drawing on the same research partnership, added more detail. 64% of credit unions cited misalignment in goals or culture with fintech partners. 59% cited their own internal decision-making complexity. And 61% said faster implementation is a main reason they partner at all.

So credit unions partner with fintechs to move faster. Then the partnership itself turns out to be slow. Both sides see the problem, and each tends to locate it on the other side of the table.

Fintechs are still coming

None of this is slowing interest. A September 2026 PYMNTS Intelligence and Velera report, FinTechs Want In: How Credit Unions Can Turn Partnerships Into Growth, looked at fintechs that do not yet sell to credit unions.

48% said they are very or extremely likely to start selling to credit unions within three years. In November 2023, that figure was 4%. Including fintechs who are “somewhat likely,” 74% are open to entering the market.

The same report found two other things worth noting:

• 50% of fintechs said credit union infrastructure is not suited to new technology
• 36% cited credit union budget constraints, which ranked lower than other barriers

And among hesitant fintechs, 58% said a bundled, one-time onboarding process would make them more likely to partner. That share was 21% in November 2024.

Put simply, more fintechs are lining up to sell to credit unions, and the main thing holding them back is the work of getting set up. Budget ranks lower on the list.

What credit unions are spending on

Cornerstone Advisors’ What’s Going On in Banking 2026 report gives a sense of where credit union attention is going right now.

Roughly 50% of credit unions and 40% of banks reported higher fraud losses in 2025. First-party fraud made up more than 40% of total fraud losses. About three-quarters of institutions are increasing fraud prevention budgets.

On the technology side, 59% of credit unions have deployed generative AI, compared with 49% of banks. Agentic AI has come up at the executive or board level at more than half of institutions.

Fraud and AI are the two topics with budget behind them. A fintech with a credible story in either area has a reason to get a meeting.

What this means for fintech marketing

Here is how we read all of this when we plan programs for fintech clients.

Market the implementation, early. Credit unions have learned that projects run late. A content asset that shows a realistic implementation timeline, with the steps the credit union’s own team will own, answers the question they are already worried about. Expect this kind of asset to pull fewer downloads than a broad trend report. The people who do download it are usually further along.

Write for the partner-light credit union. Only 12% of credit unions under $500 million in assets build their own innovations, so many of your buyers have small IT teams. Content that explains what you handle and what they handle is more useful to them than feature lists.

Show how onboarding works. With 58% of hesitant fintechs asking for simpler onboarding, it is fair to assume credit unions feel the same pain from their side. A short guide to what onboarding with your company looks like (documents, timeline, who is involved) lowers the perceived cost of saying yes.

Expect a long nurture. When 0% of projects finish early and many credit unions expect one to two years, the gap between first download and signed contract will be long. Leads from a credit union program should be routed into nurture with that timeline in mind, rather than judged on 30-day conversion.

Ask about stage on the form. A single question such as “when do you need this live?” or “have you started a vendor review?” tells sales which leads to call this month and which to nurture for next year.

Segment by size. The research shows big differences between small and large credit unions in how they build and how they buy. Running one campaign to all credit unions blends those signals together.

Where we fit

We run content syndication programs for fintech and payments companies, with verified leads and custom qualifying questions on every form. For credit union programs, that usually means pairing an implementation-focused asset with a question about timing, so the leads come in already sorted by how soon they can move.

The research makes one thing clear. Credit unions are going to keep partnering, and fintechs are going to keep coming. The vendors who win will likely be the ones whose content prepares the credit union for the whole project, from onboarding through go-live.

Sources

• PYMNTS, The Credit Union-FinTech Romance Continues, Even as Execution Gets Harder, March 5, 2026
• PYMNTS, Credit Unions Want FinTechs on Speed Dial, March 31, 2026
• PYMNTS, Credit Unions Could Land More FinTech Partners by Simplifying Onboarding, October 14, 2026
• Cornerstone Advisors, What’s Going On in Banking 2026 press release

Two of the largest journalist surveys of 2026 came out this spring.

One is from Cision. The other is from Muck Rack. Together they cover thousands of reporters and editors across North America, Europe and Asia Pacific.

Both point in the same direction. Journalists still lean on PR for ideas. They want data and people to interview. And most of what lands in their inbox misses the mark.

For any B2B company that publishes its own research, these numbers say a lot about how that research should reach the press.

What the Cision survey found

Cision’s 2026 State of the Media Report surveyed 1,899 journalists in 19 markets during January and February 2026. Cision published the results on May 13.

66% of journalists said they rely on PR-provided content, such as press releases, pitches and media kits, for story ideas.

When asked what they value most in a pitch, journalists named original research, access to experts and embargoed information. Cision also listed credible data among the things reporters want.

The less encouraging number: 72% of journalists said fewer than a quarter of the pitches they receive are relevant to them.

So the door is open. Most people knocking on it are at the wrong address.

What the Muck Rack survey found

Muck Rack’s State of Journalism 2026 was fielded from January 30 to March 2, 2026.

86% of journalists said at least some of their stories started with a PR pitch.

Muck Rack also asked which pitch elements journalists value most. The top four:

• Clear relevance to their beat: 70%
• Access to relevant interview sources: 58%
• Original data or research: 40%
• High-resolution images: 37%

On format, 69% of journalists prefer pitches under 200 words, and 78% prefer to receive them before noon. 43% said relevant pitches to their beat are rare.

Reading the two surveys together

Original research shows up near the top of both lists. In Muck Rack’s ranking it sits behind beat relevance and interview access.

That ordering matters. A strong dataset sent to the wrong reporter still gets ignored. The same dataset, cut for that reporter’s beat and offered with someone to interview, covers the three things journalists say they want most.

For a company that has run a survey, that usually means preparing several versions of the findings instead of one.

A reporter covering healthcare IT wants the hospital respondents. A reporter covering manufacturing wants the plant engineers. A trade editor covering procurement wants the procurement data. The full report stays the same. The pitch changes.

A pitch checklist for company research

Based on what the two surveys report, a research pitch has the best odds when it does these things:

1. Opens with one number. The headline finding goes in the first line.
2. Matches the beat. Each outlet gets the cut of the data that fits what it covers.
3. Shows the method. Sample size, field dates, who answered and who paid for the study, in one short paragraph.
4. Offers a person. Name the analyst or executive available for an interview.
5. Stays under 200 words. Link to the rest.
6. Arrives before noon. In the reporter’s time zone.
7. Includes a chart. A clean, high-resolution image of the key finding.
8. Points to an open page. Headline findings on an ungated page give reporters something to cite and link.

Why press coverage carries into AI answers

There is a second reason to care about editorial pickups in 2026.

Tools like ChatGPT, Perplexity and Google’s AI Overviews often cite third-party sites when they answer questions. A finding that only lives on a company’s own blog has one source behind it. A finding republished across trade and news sites has many.

Each pickup puts the company name and its data on an independent domain. Those pages become sources AI tools can quote when a buyer asks about the topic months later.

We have published separate research on how third-party AI citations relate to content syndication.

Pitching one reporter at a time has limits

The surveys describe the one-to-one pitch: a PR person, a reporter, a story. That still works when the fit is right.

It is also slow. Even a well-targeted research pitch reaches a handful of outlets.

Editorial syndication takes a different route. Headline findings are written as a news-style article and republished across a network of licensed publishers.

LeadSpot’s editorial syndication launches this month with licensed access to more than 3,000 editorial and news publishers. Campaigns typically earn 150 to 250 pickups.

Those two approaches work well together. Targeted pitches earn original coverage from reporters who want an interview. Syndicated pickups widen the footprint of the same findings across many more sites.

What to take from this year’s numbers

Journalists are open to company research. Two-thirds use PR content for story ideas, and most have written stories that began with a pitch.

They are also overloaded with pitches that don’t fit. The research that gets used is cut for the right beat, kept short and paired with a real person to interview.

If you are planning a study for 2027, plan the press versions at the same time as the questionnaire. It is much easier to collect the industry and role splits up front than to wish for them later.

The full LeadSpot research on using original research in syndication is here: Why Original Research Makes the Best Syndication Content.

Sources: Cision 2026 State of the Media Report press release · University of Minnesota summary of Muck Rack’s State of Journalism 2026 · Muck Rack State of Journalism 2026

Here is a situation we hear about a lot.

A small business owner opens Google Search Console, sees that one of their best blog posts has fewer clicks than it used to, and decides it needs a rewrite. They spend a weekend on it. New intro, new headings, a few extra sections, a fresh date at the top.

Sometimes that was the right call. Often the post was fine, and the drop had a cause that a rewrite could never fix.

Google publishes a guide on exactly this: debugging drops in Google Search traffic. It lists the common causes and the checks to run. We think it is one of the most useful pages a founder can read, and very few people read it.

This article walks through it step by step, using a made-up business so the steps feel concrete.

Meet the example business

Cedar Row Bike Repair is a fictional two-person shop in Duluth, Minnesota.

In 2024, the owner wrote a post called “How to get your bike ready for a Minnesota winter.” It covers cleaning the chain, switching to studded tires, and storing a bike in an unheated garage. It became the shop’s top page for organic search, and a steady source of tune-up bookings.

In April, the owner notices clicks to that post are down about 70% compared with January. The instinct is to rewrite it.

Before touching it, here is what the guide says to check.

Step 1: Compare the right periods

The first instruction in Google’s guide is to look at a longer window. In the Search Console performance report, it says to “choose the Date filter on top of the chart and select Last 16 months.”

Sixteen months matters because it lets you compare the same season across two years.

The guide is direct about this: “make sure it’s not a drop that happens every year due to a festivity or a trend.” It also notes that “changes in user behavior will change the demand for certain queries.”

For Cedar Row, the 16-month view shows the same shape last year. Clicks climbed from October to January and fell off in spring. Nobody in Duluth searches for winter bike prep in April.

That single check answers the question. The post did not get worse. Demand moved with the weather.

A rewrite in April would have changed a page that was doing its job, and the owner would have had no way to tell whether the edit helped or hurt when traffic came back in the fall.

Step 2: Check which searches moved

Suppose the 16-month view had shown something different: a drop this spring that did not happen last spring. The next step is to narrow it down.

Google’s guide says to “click all tabs to find out if the change happened only for specific queries.” The performance report has tabs for queries, pages, countries, devices and search appearance. The guide also suggests trying the different search type options (web, image, video, news) and sorting by “Clicks Difference” to see which pages lost the most traffic.

This tells you whether the drop is about one post, one type of search, or the whole site. Those are very different problems.

Two things to keep in mind when reading these reports, both noted in our research review on content refreshes:

• Search Console leaves some queries out of the query table to protect searcher privacy. The page totals can be higher than the sum of the queries you can see.
• Performance data is credited to the canonical URL, which is the version of a page Google treats as the main one. If Google started treating a different URL as canonical, clicks can appear to move away from the page you are watching.

Step 3: Rule out technical problems

Google’s guide lists technical issues as a cause in their own category. Its examples include server errors, problems fetching robots.txt, “page not found” errors, and a misplaced noindex tag. A noindex tag is a line of code that tells search engines to leave a page out of results.

The guide adds that page-level problems usually cause a slower decline than site-wide ones.

For a small business site, the realistic version of this check is short:

1. Open the post in a private browser window and confirm it loads.
2. Run the URL through the URL Inspection tool in Search Console and confirm it is indexed.
3. Ask whoever manages the site whether anything changed recently: a theme update, a plugin, a new SEO setting, a URL change.

A lot of mystery drops on small sites trace back to step 3. A plugin update flips a setting, or a page gets moved and the old URL never gets redirected.

None of those are content problems. Rewriting the post would leave the actual fault in place.

Step 4: Look at the other causes on Google’s list

The guide names several more causes:

• Algorithmic updates. Google says “small fluctuations in position can happen at any time.” Large drops after a core update may call for a broader review of the site, not one page.
• Security issues. Malware or phishing can trigger browser warnings that stop visitors before they reach you. Search Console has a Security Issues report.
• Spam issues and manual actions. These show up in Search Console’s Manual Actions report.
• Site moves and migrations. Google says fluctuations after URL changes can last while it recrawls the site, which can take weeks or longer.
• Data issues. Reporting glitches can look like drops. Google keeps a Data Anomalies page listing known problems with its own numbers.

Each of these takes a few minutes to check. Together they cover most of the drops that have nothing to do with the words on the page.

Step 5: Decide whether the post has a reader problem

If you have worked through steps 1 to 4 and still cannot explain the drop, it is time to read the post itself. Read it the way a customer would.

The question to ask: is there something in this post that is wrong, missing or harder to use than it should be?

For Cedar Row, that might look like:

• The post recommends a tire model the shop no longer stocks.
• It lists a winter tune-up price from 2024.
• A customer asked about e-bike batteries in the cold, and the post does not mention them.

Those are real reasons to edit. Each one is a specific fact a reader would notice.

Our research review puts it this way: a refresh needs a specific correction, such as a wrong price, an outdated setting, or a central question the page does not answer. An old date on its own is not one of those.

If nothing is wrong and the drop has an explanation, Google’s own guide supports leaving it alone. It says “we recommend avoiding making radical changes if your page is already performing well.”

Step 6: Write down what you expect before you edit

This is the step almost everyone skips.

Before changing the page, write two or three lines in a notes file:

• What you are fixing and why (“price is out of date, battery question unanswered”).
• What you will compare afterward (“clicks to this URL, October to January, against last year’s October to January”).
• What else is happening in that window that could affect the result (“new shop location opens in November”).

Without this note, any change in traffic afterward is hard to read. Traffic might rise because of the edit, because of the season, or because of a Google update, and you will not be able to tell which.

It also helps to judge the edit on two separate questions. Did it fix the reader’s problem? And did search performance change? The first one you can confirm the day you publish. The second can take months and has many causes.

Step 7: When you do edit, keep the signals honest

If the post needs work, a few rules from Google’s documentation keep the update clean:

• Update the visible date only when the content has substantially changed. Google’s helpful content guidance lists changing dates “to make them seem fresh when the content has not substantially changed” as a warning sign.
• Keep the same URL so the post keeps its history.
• Fix every place the old fact appears, including image captions and screenshots.

A note on AI assistants

Everything above comes from Google’s documentation and applies to Google Search.

ChatGPT, Perplexity and other AI assistants do not publish an equivalent troubleshooting guide. If you are tracking whether an AI assistant cites your post, record the question you asked, the date, the platform and the URL it cited. That gives you something to compare against later, and keeps one-off answers from looking like trends.

The short version

When an old post loses traffic, check the season first, then the searches that moved, then the technical setup, then the rest of Google’s list.

Edit when you can name what is wrong for the reader.

Write down what you expect before you publish.

For Cedar Row, the answer was to wait for October. For your post, the checks above will tell you.

This article draws on our research review, When Is a Content Refresh Worth Doing?, and on Google’s guide to debugging search traffic drops.

Most advice about robots.txt tells you which bot names to list.

Very little of it explains how a crawler reads the file once it arrives. That part decides what actually happens, and it follows a published standard, RFC 9309, that almost nobody outside of engineering has opened.

We read it so you don’t have to. Here’s how the rules work, walked through with one small business.

Meet Harbor Lane

Harbor Lane Tile & Stone is a fictional tile shop in Portland, Maine. Two owners, one showroom, a website built on a template.

Their site has three kinds of pages:

• Public pages: services, a gallery of finished bathrooms, an FAQ about heated floors.
• A trade pricing page at /trade-pricing/ for contractors who buy in volume.
• A booking page for showroom visits.

A few years ago someone added this to their robots.txt:

User-agent: *
Disallow: /trade-pricing/

The * means "every crawler." The rule asks all of them to stay out of the trade pricing folder.

So far, so reasonable.

The line they added this fall

This year the owners read that ChatGPT search uses a crawler called OAI-SearchBot. OpenAI’s documentation says sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers.

They wanted to be found. So they added a welcome:

User-agent: *
Disallow: /trade-pricing/

User-agent: OAI-SearchBot
Allow: /

It looks like a small, friendly addition.

Here’s what it does under the standard: OAI-SearchBot is now allowed into /trade-pricing/.

Why that happens

RFC 9309 says a crawler looks for a group of rules that names it. If one exists, the crawler follows that group. The * group only applies when no group names the crawler.

The two groups do not stack. A crawler with its own group never reads the wildcard rules at all.

So once Harbor Lane gave OAI-SearchBot its own group, the Disallow: /trade-pricing/ line stopped applying to it. The only rule OAI-SearchBot sees is Allow: /.

We checked this with Python’s built-in robots.txt parser. Against the file above, OAI-SearchBot gets “allowed” for /trade-pricing/. GPTBot and ClaudeBot, which have no group of their own, still get "disallowed."

The outwrite.ai research review published November 4 ran a larger version of this check: 18 local tests, nine agent strings against two paths, on a fictional file. The pattern is the same. Every named group has to carry its own restrictions.

The fix for Harbor Lane

Repeat the restriction in every named group:

User-agent: *
Disallow: /trade-pricing/

User-agent: OAI-SearchBot
Disallow: /trade-pricing/
Allow: /

Now the search crawler can read the gallery and the FAQ, and is still asked to skip the trade pricing.

If they later add groups for Claude-SearchBot or anyone else, each one needs the same line.

Rule two: the longest path wins

Inside a group, a page can match more than one rule.

Say Harbor Lane keeps a /guides/ folder of half-finished drafts, but wants one finished guide crawled:

User-agent: *
Disallow: /guides/
Allow: /guides/heated-floors/

RFC 9309 says the most specific match wins, and “most specific” means the rule with the most characters. /guides/heated-floors/ is longer than /guides/, so that guide is allowed while the rest of the folder stays disallowed.

If an Allow and a Disallow rule are equally long, the standard says the Allow rule should be used.

Order in the file does not decide this. Length does.

Rule three: what happens when the file itself breaks

This part surprises people.

RFC 9309 treats a missing file and a broken server very differently.

If yoursite.com/robots.txt returns a 4xx error (most often a 404, meaning the file isn't there), crawlers may access any page on the site. No file means no requests.

If it returns a 5xx error (the server is failing), crawlers must assume everything is disallowed.

So a host outage that breaks the robots.txt address can, for a while, read to compliant crawlers as “stay out of the whole site.” The standard says that if the file stays unreachable for a long time (it gives 30 days as an example), crawlers may treat it as missing or fall back to a cached copy.

Rule four: changes are not instant

The standard lets crawlers cache your robots.txt, and says they should not use a cached copy for more than 24 hours unless the file is unreachable.

OpenAI says changes for its search crawler can take about 24 hours to take effect after you update robots.txt.

If Harbor Lane fixes the file at 9 a.m., they should not expect a change in behavior before the next day. Plan edits with that lag in mind, especially before a launch.

Rule five: some requests aren’t crawling

robots.txt is written for automated crawlers. Some AI tools also fetch a page because a person asked them to.

OpenAI’s agent for this is ChatGPT-User. OpenAI says that because these actions are initiated by a user, robots.txt rules may not apply.

Anthropic documents a similar agent, Claude-User, and says blocking it prevents Claude from retrieving your content in response to a user query.

The two providers describe this differently, so it’s worth reading each one’s page instead of assuming they match.

Rule six: the file is a public note

Anyone can open yoursite.com/robots.txt in a browser. That includes competitors and curious customers.

RFC 9309 says its rules “are not a form of access authorization,” and notes that the paths listed in the file are publicly discoverable.

For Harbor Lane, this means the line Disallow: /trade-pricing/ tells every visitor where the contractor prices live. If those prices are meant for contractors only, the page needs a login or a password. robots.txt can ask polite crawlers to skip it. It cannot stop anyone from opening it.

A 15-minute check for your own site

1. Open yoursite.com/robots.txt and copy it into a document.
2. List every User-agent line. Note which ones are named bots and whether there's a * group.
3. For each named group, check that it repeats every Disallow line from the * group that you still want to apply.
4. Look for any path in the file that you’d be uncomfortable with a stranger reading. Move that content behind a login.
5. Open the private pages in a private browser window while signed out. If they load, they’re public, whatever robots.txt says.
6. After any change, wait a day before checking crawler behavior in your server logs.

None of this requires a developer for the diagnosis. The fixes are usually a few lines.

Where outwrite.ai fits

Getting the file right lets AI search crawlers read your public pages. It doesn’t decide whether those pages get cited.

That’s the part we built outwrite.ai for. It scans your domain, shows which AI answers name your competitors for the questions your buyers ask, and writes pages structured for those answers. The domain scan is free at outwrite.ai.

The provider-by-provider review that started this article is here: AI Search Crawlers and Training Controls: What Publishers Can Choose.

Harbor Lane Tile & Stone is a fictional business used for illustration. Rules described here are from RFC 9309 and provider documentation read November 4, 2026. They describe how compliant crawlers are meant to behave, not measured crawler behavior.

Sources

• IETF RFC 9309: Robots Exclusion Protocol
• OpenAI: Overview of OpenAI crawlers
• Anthropic: Does Anthropic crawl data from the web?
• outwrite.ai: AI Search Crawlers and Training Controls