Your Website Is A Source, Not A Megaphone via @sejournal, @slobodanmanic

There’s a lesson from the early days of social media that most brands eventually learned the hard way: Social media is not a megaphone.

You couldn’t just broadcast your press releases into the feed and expect people to care. The channel had rules. It rewarded conversation, not announcements. The companies that figured this out early thrived. The rest spent years shouting into a void, wondering why nobody was engaging.

We’re watching the same mistake happen again, just one layer deeper. This time it’s not about which platform you’re on. It’s about assuming your website is where the message lives.

Why Most Websites Break When AI Agents Read Them

Most websites are still built on a core assumption: Someone will arrive at your front door, navigate your carefully designed pages, and consume your message in the exact sequence and format you intended.

That assumption is breaking.

In 2026, your website is no longer the only interface to your content. An AI agent might summarize your service page for someone mid-conversation. A voice assistant might read your pricing aloud, stripped of all visual hierarchy. A research tool might pull three paragraphs from your blog, recontextualize them alongside a competitor’s, and present them in a comparison the user never asked you for. Someone might never visit your site and still make a decision based entirely on what your website says.

If your message only works when it’s wrapped in your layout, your fonts, your carefully choreographed scroll, you don’t have a message. You have a brochure. And brochures don’t travel well.

The shift that’s happening is subtle but fundamental: You need to design the message independently of the medium.

This doesn’t mean your website stops mattering. It means your website is now one of many surfaces where your message might land. And the message has to hold up in all of them. It has to make sense when it’s read in full, when it’s summarized in three sentences, when it’s pulled apart and reassembled by something you didn’t build and don’t control.

That changes how you write. It changes how you structure information. It changes what you think of as “the product” of your content work.

Here’s a simple test: If there’s a single “Lorem ipsum” anywhere in your website while it’s being built, the message came second. The design came first. That order no longer works.

A few things this means in practice:

Your core message needs to be extractable. If an agent grabs one paragraph from your website, does that paragraph carry weight on its own, or does it collapse without the paragraphs around it?

Your value proposition can’t hide behind design. Bold typography and hero animations don’t travel through an API. The words have to do the work.

Structure becomes a form of portability. Clear headings, logical hierarchy, well-defined claims. These aren’t just good for traditional SEO anymore. They’re how machines parse your intent and relay it accurately.

You need to think about your content the way a news agency thinks about a wire story. The story has to work no matter which publication picks it up, no matter how they crop it, no matter what headline they slap on it. The facts and the narrative have to be embedded in the text itself, not in the presentation layer.

Brand Control When AI Recontextualizes At Scale

There’s a natural resistance to this idea. “If I don’t control the experience, how do I control the brand?” But that’s the megaphone instinct talking. The desire to control exactly how every word lands, in exactly the right font, with exactly the right whitespace. That was always a bit of an illusion anyway. People skim. People read on phones in bad lighting. People copy-paste your pricing into a Slack thread with zero context.

The difference now is that the recontextualization is happening at scale, automatically, and often before a human even sees it.

So, the question isn’t how to prevent that. It’s how to make sure your message is strong enough to survive it.

Websites As Canonical Sources, Not Just Destinations

Your website still matters. But its job description has changed.

Your website is no longer just a destination. It’s a source. It’s the canonical, structured, well-maintained origin point from which your message gets picked up, interpreted, summarized, and carried elsewhere. The better that source material is, the better it travels.

Think of it this way: Your website used to be the store. Now, it’s also the warehouse. And the warehouse needs to be organized well enough that anyone (human or machine) can find what they need, understand what it means, and carry it somewhere else without losing the plot.

The companies that get this right will be the ones whose message shows up clearly, no matter where the conversation is happening. The ones that don’t will keep designing beautiful megaphones, and keep wondering why the room isn’t listening.

More Resources:


This post was originally published on No Hacks.


Featured Image: Pixel-Shot/Shutterstock

Google Tells Developers To Build For AI Agents, Not Just Humans via @sejournal, @MattGSouthern

Google’s web.dev site now includes guidance advising developers to treat AI agents as a distinct audience alongside human visitors.

Titled “Build agent-friendly websites,” it tells developers that “some human users are pivoting from manual navigation to delegating goal-oriented journeys to AI agents.”

Google frames this as a design problem, noting that websites built with complex hover states and shifting layouts are “functionally broken for agents.”

What The Guide Covers

Google describes three ways agents interpret websites:

  1. Screenshots let agents use vision models to identify elements visually.
  2. Raw HTML gives agents the DOM structure and hierarchy.
  3. And the accessibility tree provides what Google calls a “high-fidelity map” of interactive elements, stripped of visual noise.

Google’s recommendations for agent-friendly design include using semantic HTML elements like and over styled

elements, keeping layouts stable across pages, linking tags to inputs with the for attribute, and setting cursor: pointer on clickable elements.

Google wraps up with a statement that highlights the connection between agent optimization and current web standards:

“Everything we suggest to make a site ‘agent-ready’ also makes sites better for humans.”

WebMCP As A Forward Signal

At the bottom of the guide, Google links to WebMCP, a proposed web standard for helping websites interact with agents. Chrome’s team describes it as an early preview program and is accepting sign-ups for developers who want to experiment.

WebMCP would let websites register tools with defined input/output schemas that agents can discover and call as functions. Slobodan Manic covered WebMCP last week as part of the broader protocol stack forming around agent interaction.

Why This Matters

Semantic HTML, stable layouts, and proper accessibility markup have been web development defaults for years, and we’ve covered agent-optimization in depth.

What’s new is Google making this an official developer resource. Putting agent-friendliness on web.dev signals that Google is treating agent interaction as part of its developer guidance, alongside established areas like accessibility and performance.

For sites that already follow accessibility best practices, there’s little to change. For those that don’t, the business case for semantic HTML now extends beyond screen readers to AI agents that browse, compare, and transact on behalf of users.

Looking Ahead

The WebMCP early preview program is open for sign-ups. Chrome is listed for Google I/O on May 19–20, giving developers another place to watch for updates on browser-based agent interactions.


Featured Image: Summit Art Creations/Shutterstock

The Fully Non-Human Web: No One Builds The Page, No One Visits It via @sejournal, @slobodanmanic

In January 2026, Google was granted patent US12536233B1. Six engineers worked on it, and it describes a system that scores a landing page on conversion rate, bounce rate, and design quality. If the landing page falls below a threshold, generate an AI replacement personalized to the searcher. The advertiser never sees it. Never approves it. Might not even know it happened.

The debate around this patent has centered on scope: Is it limited to shopping ads, or does it signal something broader? That’s the wrong question.

The right question: What happens when you combine AI-generated pages with AI agents that browse, shop, and transact on behalf of humans?

For the first time, we have the infrastructure for a web where no human creates the page and no human visits it. Both sides can be non-human. That changes everything.

The Supply Side: AI-Generated Pages

The supply side of the web has always been human. Someone designs a page, writes copy, publishes it. Three developments are changing that.

Google’s patent US12536233B1 is the most direct: Score a landing page on conversion rate, bounce rate, and design quality, then replace underperforming pages with AI-generated versions. The replacement pages draw on the searcher’s full search history, previous queries, click behavior, location, and device data. Google builds personalized landing pages no advertiser can match, because no advertiser has access to cross-query behavioral data at that scale. Barry Schwartz covered the patent on Search Engine Land, describing a system where Google could automatically create custom landing pages, replacing organic results. Glenn Gabe called Google’s AI landing page patent potentially more controversial than AI Overviews. Roger Montti at Search Engine Journal argued the patent’s scope is limited to shopping and ads. Both camps agree: the technology to score and replace landing pages with AI exists and works.

NLWeb, Microsoft’s open project, takes a different approach. NLWeb turns any website into a natural language interface using existing Schema.org markup and RSS feeds. An AI agent querying an NLWeb-enabled site doesn’t load a page at all. The agent asks a structured question, NLWeb returns a structured answer. The rendered page becomes optional.

WebMCP goes further still. With WebMCP, a website registers tools with defined input/output schemas that AI agents discover and call as functions. A product search becomes a function call. A checkout becomes an API request. WebMCP eliminates the “page” concept entirely, dissolving the web page as a unit of content into a set of callable capabilities.

Each mechanism works differently, but the direction is the same: the page is becoming something generated, queried, or bypassed entirely. The human-designed, human-published web page is no longer the only way content reaches an audience.

The Demand Side: AI Agents As Visitors

The demand side shifted faster. In 2024, bots surpassed human traffic for the first time in a decade, accounting for 51% of all web activity. Cloudflare’s data shows AI “user action” crawling (agents actively doing things, not just indexing) grew 15x during 2025. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from less than 5% in 2025. The scale is hard to overstate.

Agentic browsers are the most visible shift. Chrome’s auto browse turned 3 billion Chrome installations into potential AI agent launchpads. Google’s Gemini scrolls, clicks, fills forms, and completes multi-step tasks autonomously inside Chrome. Perplexity’s Comet browser conducts deep research across multiple sites simultaneously. Microsoft’s Edge Copilot Mode handles multi-step workflows from within the browser sidebar. The full agentic browser landscape now includes over a dozen consumer and developer tools, all browsing on behalf of humans.

Commerce agents have moved past browsing into buying. OpenAI launched Instant Checkout to let users purchase products directly inside ChatGPT, powered by Stripe’s Agentic Commerce Protocol (ACP). OpenAI killed the feature in March 2026 after near-zero purchase conversions and only a dozen merchant integrations out of over a million promised. The failure was execution, not concept: Alibaba’s Qwen app processed 120 million orders in six days in February 2026 because Alibaba owns the AI model, the marketplace, the payment rails (Alipay), and the logistics. OpenAI tried to replicate agentic commerce without owning the stack. Google and Shopify’s Universal Commerce Protocol (UCP) connects over 20 companies, including Walmart, Target, and Mastercard, in a framework designed for AI agents to handle commerce from product discovery through checkout. Shopify auto-opted over a million merchants into agentic shopping experiences with ChatGPT, Copilot, and Perplexity. The transaction happens in an AI conversation. No checkout page loads.

Agent-to-agent communication removes the human from both ends. Google’s Agent-to-Agent (A2A) protocol lets AI agents from different vendors discover each other’s capabilities and collaborate on tasks without human mediation. A travel planning agent negotiates directly with a booking agent. A procurement agent evaluates supplier agents across vendors. Over 150 organizations support A2A, including Salesforce, SAP, and PayPal, making agent-to-agent commerce and coordination a production reality.

When Both Sides Go Non-Human

Until now, one side of the web was always human. A person built the page, or a person visited it. Usually both.

Google’s patent closes the circuit.

Here’s what a complete non-human flow might look like. A user tells their AI assistant they need running shoes. The assistant queries product data through NLWeb or WebMCP, no page load needed. The assistant evaluates options by checking inventory across retailers via A2A. If the user needs to review a comparison, Google generates a landing page personalized to that specific user’s search history and preferences. The assistant completes checkout through ACP or UCP using Shared Payment Tokens. The user receives a confirmation.

The human’s role in that entire flow: stating intent and approving the purchase. Discovery, page generation, product evaluation, and transaction completion are all handled by AI systems. The human touches only the two endpoints of the chain.

Every piece of technology in that chain exists in production today. Chrome auto browse is live for 3 billion Chrome users. A2A has 150+ organizational supporters. ACP underpins Stripe’s agentic commerce infrastructure (ChatGPT’s Instant Checkout failed on execution, not protocol). UCP connects Shopify, Google, Walmart, and Target. Patent US12536233B1 is granted. No single company has assembled the full loop yet, but every component is operational.

Who’s Building The Non-Human Web

Here’s where it gets interesting. Map out who’s building what, and a pattern emerges:

Layer What Who
Page generation AI landing pages Google
Content-as-API WebMCP, NLWeb Google, Microsoft
Agent infrastructure MCP, A2A Anthropic, Google
Agent browsers Chrome, Comet, Copilot Google, Perplexity, Microsoft
Agent commerce ACP, UCP Stripe + OpenAI, Shopify + Google
Edge delivery Markdown for Agents Cloudflare

Google appears in five of six layers: page generation (patent US12536233B1), content-as-API (WebMCP), agent infrastructure (A2A), agent browsers (Chrome auto browse), and commerce (UCP). Google is positioning itself to mediate the non-human web the same way Google mediates the human one through Search.

The Agentic AI Foundation (AAIF), formed under the Linux Foundation with Anthropic, OpenAI, Google, and Microsoft as platinum members, provides the governance layer. The AAIF functions as the W3C for the agentic web: the vendor-neutral body that decides which protocols become standards for agent interoperability.

What Website Owners Need To Know

This isn’t an optimization checklist. It’s three structural shifts in what your website is for.

Your Data Layer Is Your Website

Google’s patent generates landing pages from product feed data, making product feeds the most important asset an ecommerce business maintains. NLWeb queries Schema.org markup instead of rendering pages, making structured markup the front door to your content. WebMCP exposes site capabilities as function calls, making tool definitions the user interface agents interact with.

Structured data, product feeds, JSON-LD, and API surfaces have traditionally been treated as backend infrastructure. In the non-human web, these data layers become the primary way a business reaches customers. Product feed accuracy (specs, pricing, stock levels, images) matters more than homepage design when AI systems generate the page from that feed.

Trust Is The Moat

AI can generate a page. It cannot generate a reason to seek you out by name.

Direct traffic, email subscribers, community members, and brand reputation persist when the page itself becomes replaceable. An AI agent can build a product page, but no AI agent can build the trust that makes a consumer (or their agent) request a specific brand by name.

The brands that matter in the non-human web are the ones people tell their agents to find. “Get me a fleece jacket” is a commodity query. “Get me a fleece jacket from Patagonia” is a brand moat.

The Measurement Problem

How do you measure a page you didn’t build? How do you A/B test against something Google generates dynamically? How do you attribute a conversion that happened inside ChatGPT, initiated by an agent acting on behalf of a user who never saw your website?

Traditional web analytics (page views, sessions, bounce rate, time on site) assume two things: a human visitor and a page you control. On the non-human web, neither assumption holds. A Google-generated landing page isn’t yours. A ChatGPT checkout session doesn’t register in your analytics.

I don’t have a clean answer here, and neither does anyone else. Measurement is the genuinely unsolved problem of the non-human web. New metrics will need to track agent discoverability, agent conversion rate, and data feed quality. But as of March 2026, the measurement infrastructure hasn’t caught up to the technology it needs to measure.

Four Predictions For 2026-2027

Four things to watch over the next 12-18 months.

Google ships patent US12536233B1, or something like it. The technology for scoring and replacing landing pages exists. The business incentive exists. Google has a history of introducing features in ads first, then expanding (Google Shopping went from free to paid to essential). AI-generated landing pages will likely appear in shopping ads first, then broaden to other verticals. Landing page quality scores in Google Ads serve as the early warning system for which pages Google considers replaceable.

Agent traffic becomes measurable. Analytics platforms will need to distinguish human sessions from agent sessions. BrightEdge reports AI agents account for roughly 33% of organic search activity as of early 2026. WP Engine’s traffic data shows 1 AI bot visit for every 31 human visits by Q4 2025, up from 1 per 200 at the start of that year. Agent traffic ratios will accelerate further as Chrome auto browse rolls out globally beyond the US. New metrics around agent conversion rate and agent discoverability will emerge from necessity.

The protocol stack consolidates. MCP, A2A, NLWeb, and WebMCP form a coherent stack covering tool access, agent communication, content querying, and browser-level integration. Expect more interoperability between these protocols and fewer competing standards. The Agentic AI Foundation (AAIF) accelerates consolidation. Within 18 months, “does your site support MCP?” will be as standard a question as “is your site mobile-friendly?”

Brand differentiation gets harder and more important. When AI generates pages and agents do the shopping, the only defensible position is being the brand people (and their agents) seek out by name. Direct relationships, owned audiences, trust signals. Everything else is a commodity.

The Web Splits In Two

When Shopify auto-opted merchants into agentic shopping, I asked whether your website just became optional. The answer is more nuanced than optional or essential. It’s becoming something different.

The web isn’t dying. It’s splitting.

The transactional web (product listings, checkout flows, information retrieval, comparison shopping) is going non-human first. AI generates the landing pages. AI agents visit and transact on those pages. Humans approve decisions at the endpoints. Google’s patent lives in the transactional web, and the economics of conversion optimization push hardest toward automation in this layer.

The experiential web (brand storytelling, community, content that rewards sustained attention, design that creates emotional response) stays human. Not because AI can’t generate brand experiences, but because the value of those experiences comes from the human connection behind them. Nobody tells their agent to “go enjoy a brand experience on my behalf.”

Your website’s new job description: data source for the agents, trust anchor for the humans, brand home for both. The companies that treat their structured data, product feeds, and API surfaces with the same care they give their homepage design are the ones that show up in both worlds.

The non-human web isn’t replacing the human web. It’s growing alongside it. Your job is to show up in both.

More Resources:


This was originally published on No Hacks.


Featured Image: Yaaaaayy/Shutterstock

Cloudflare’s New Markdown for AI Bots: What You Need To Know via @sejournal, @MattGSouthern

Cloudflare launched a feature that converts HTML pages to markdown when AI systems request it. Sites on its network can now serve lighter content to bots without building separate pages.

The feature, called Markdown for Agents, works through HTTP content negotiation. An AI crawler sends a request with Accept: text/markdown in the header. Cloudflare intercepts it, fetches the original HTML from the origin server, converts it to markdown, and delivers the result.

The launch arrives days after Google’s John Mueller called the idea of serving markdown to AI bots “a stupid idea” and questioned whether bots can even parse markdown links properly.

What’s New

Cloudflare described the feature as treating AI agents as “first-class citizens” alongside human visitors. The company used its own blog post as an example. The HTML version consumed 16,180 tokens while the markdown conversion used 3,150 tokens.

“Feeding raw HTML to an AI is like paying by the word to read packaging instead of the letter inside,” the company wrote.

The conversion happens at Cloudflare’s edge network, not at the origin server. Websites enable it per zone through the dashboard, and it’s available in beta at no additional cost for Pro, Business, and Enterprise plan customers, plus SSL for SaaS customers.

Cloudflare noted that some AI coding tools already send the Accept: text/markdown header. The company named Claude Code and OpenCode as examples.

Each converted response includes an x-markdown-tokens header that estimates the token count of the markdown version. Developers can use this to manage context windows or plan chunking strategies.

Content-Signal Defaults

Converted responses include a Content-Signal header set to ai-train=yes, search=yes, ai-input=yes by default, signaling the content can be used for AI training, search use, and AI input (including agentic use). Whether a given bot honors those signals depends on the bot operator. Cloudflare said the feature will offer custom Content-Signal policies in the future.

The Content Signals framework, which Cloudflare announced during Birthday Week 2025, lets site owners set preferences for how their content gets used. Enabling markdown conversion also applies a default usage signal, not just a format change.

How This Differs From What Mueller Criticized

Mueller was criticizing a different practice. Some site owners build separate markdown pages and serve them to AI user agents through middleware. Mueller raised concerns about cloaking and broken linking, and questioned whether bots could even parse markdown properly.

Cloudflare’s feature uses a different mechanism. Instead of detecting user agents and serving alternate pages, it relies on content negotiation. The same URL serves different representations based on what the client requests in the header.

Mueller’s comments addressed user-agent-based serving, not content negotiation. In a Reddit thread about Cloudflare’s feature, Mueller responded with the same position. He wrote, “Why make things even more complicated (parallel version just for bots) rather than spending a bit of time improving the site for everyone?”

Google defines cloaking as showing different content to users and search engines with the intent to manipulate rankings and mislead users. The cloaking concern may apply differently here. With user-agent sniffing, the server decides what to show based on who’s asking. With content negotiation, the client requests a format and the server responds. The content is the same information in a different format, not different content for different visitors.

The practical result is still similar from a crawler’s perspective. Googlebot requesting standard HTML would see a full webpage. An AI agent requesting markdown would see a stripped-down text version of the same page.

New Radar Tracking

Cloudflare also added content type tracking to Cloudflare Radar for AI bot traffic. The data shows the distribution of content types returned to AI agents and crawlers, broken down by MIME type.

You can filter by individual bot to see what content types specific crawlers receive. Cloudflare showed OAI-SearchBot as an example, displaying the volume of markdown responses served to OpenAI’s search crawler.

The data is available through Cloudflare’s public APIs and Data Explorer.

Why This Matters

If you already run your site through Cloudflare, you can enable markdown conversion with a single toggle instead of building separate markdown pages.

Enabling Markdown for Agents also sets the Content-Signal header to ai-train=yes, search=yes, ai-input=yes by default. Publishers who have been careful about AI access to their content should review those defaults before toggling the feature on.

Looking Ahead

Cloudflare said it plans to add custom Content-Signal policy options to Markdown for Agents in the future.

Mueller’s criticism focused on separate markdown pages, not on standard content negotiation. Google hasn’t addressed whether serving markdown through content negotiation falls under its cloaking guidelines.

The feature is opt-in and limited to paid Cloudflare plans. Review the Content-Signal defaults before enabling it.

Google Updates Googlebot File Size Limit Docs via @sejournal, @MattGSouthern

Google updated its Googlebot documentation to clarify information about file size limits.

The change involves moving information about default file size limits from the Googlebot page to Google’s broader crawler documentation. Google also updated the Googlebot page to be more specific about Googlebot’s own limits.

What’s New

Google’s documentation changelog describes the update as a two-part clarification.

The default file size limits that previously lived on the Googlebot page now appear in the crawler documentation. Google said the original location wasn’t the most logical place because the limits apply to all of Google’s crawlers and fetchers, not just Googlebot.

With the defaults now housed in the crawler documentation, Google updated the Googlebot page to describe Googlebot’s specific file size limits more precisely.

The crawling infrastructure docs list a 15 MB default for Google’s crawlers and fetchers, while the Googlebot page now lists 2 MB for supported file types and 64 MB for PDFs when crawling for Google Search.

The crawler overview describes a default limit across Google’s crawling infrastructure, while the Googlebot page describes Google Search–specific limits for Googlebot. Each resource referenced in the HTML, such as CSS and JavaScript, is fetched separately.

Why This Matters

This fits a pattern Google has been running since late 2025. In November, Google migrated its core crawling documentation to a standalone site, separating it from Search Central. The reasoning was that Google’s crawling infrastructure serves products beyond Search, including Shopping, News, Gemini, and AdSense.

In December, more documentation followed, including faceted navigation guidance and crawl budget optimization.

The latest update continues that reorganization. The 15 MB file size limit was first documented in 2022, when Google added it to the Googlebot help page. Mueller confirmed at the time that the limit wasn’t new. It had been in effect for years. Google was just putting it on the record.

When managing crawl budgets or troubleshooting indexing on content-heavy pages, Google’s docs now describe the limits differently depending on where you look.

The crawling infrastructure overview lists 15 MB as the default for all crawlers and fetchers. The Googlebot page lists 2 MB for HTML and supported text-based files, and 64 MB for PDFs. Google’s changelog does not explain how these figures relate to one another.

Default limits now live in the crawler overview documentation, while Googlebot-specific limits are on the Googlebot page.

Looking Ahead

Google’s documentation reorganization suggests there will likely be more updates to the crawling infrastructure site in the coming months. By separating crawler-wide defaults from product-specific documentation, Google can more easily document new crawlers and fetchers as they are introduced.

OpenAI Search Crawler Passes 55% Coverage In Hostinger Study via @sejournal, @MattGSouthern

Hostinger analyzed 66 billion bot requests across more than 5 million websites and found that AI crawlers are following two different paths.

LLM training bots are losing access to the web as more sites block them. Meanwhile, AI assistant bots that power search tools like ChatGPT are expanding their reach.

The analysis draws on anonymized server logs from three 6-day windows, with bot classification mapped to AI.txt project classifications.

Training Bots Are Getting Blocked

The starkest finding involves OpenAI’s GPTBot, which collects data for model training. Its website coverage dropped from 84% to 12% over the study period.

Meta’s ExternalAgent was the largest training-category crawler by request volume in Hostinger’s data. Hostinger says this training-bot group shows the strongest declines overall, driven in part by sites blocking AI training crawlers.

These numbers align with patterns I’ve tracked through multiple studies. BuzzStream found that 79% of top news publishers now block at least one training bot. Cloudflare’s Year in Review showed GPTBot, ClaudeBot, and CCBot had the highest number of full disallow directives across top domains.

The data quantifies what those studies suggested. Hostinger interprets the drop in training-bot coverage as a sign that more sites are blocking those crawlers, even when request volumes remain high.

Assistant Bots Tell a Different Story

While training bots face resistance, the bots that power AI search tools are expanding access.

OpenAI’s OAI-SearchBot, which fetches content for ChatGPT’s search feature, reached 55.67% average coverage. TikTok’s bot grew to 25.67% coverage with 1.4 billion requests. Apple’s bot reached 24.33% coverage.

These assistant crawls are user-triggered and more targeted. They serve users directly rather than collecting training data, which may explain why sites treat them differently.

Classic Search Remains Stable

Traditional search engine crawlers held steady throughout the study. Googlebot maintained 72% average coverage with 14.7 billion requests. Bingbot stayed at 57.67% coverage.

The stability contrasts with changes in the AI category. Google’s main crawler faces a unique position since blocking it affects search visibility.

SEO Tools Show Decline

SEO and marketing crawlers saw declining coverage. Ahrefs maintained the largest footprint at 60% coverage, but the category overall shrank. Hostinger attributes this to two factors. These tools increasingly focus on sites actively doing SEO work. And website owners are blocking resource-intensive crawlers.

I reported on the resource concerns when Vercel data showed GPTBot generating 569 million requests in a single month. For some publishers, the bandwidth costs became a business problem.

Why This Matters

The data confirms a pattern that’s been building over the past year. Site operators are drawing a line between AI crawlers they’ll allow and those they won’t.

The decision comes down to function. Training bots collect content to improve models without sending traffic back. Assistant bots fetch content to answer specific user questions, which means they can surface your content in AI search results.

Hostinger suggests a middle path: block training bots while allowing assistant bots that drive discovery. This lets you participate in AI search without contributing to model training.

Looking Ahead

OpenAI recommends allowing OAI-SearchBot if you want your site to appear in ChatGPT search results, even if you block GPTBot.

OpenAI’s documentation clarifies the difference. OAI-SearchBot controls inclusion in ChatGPT search results and respects robots.txt. ChatGPT-User handles user-initiated browsing and may not be governed by robots.txt in the same way.

Hostinger recommends checking server logs to see what’s actually hitting your site, then making blocking decisions based on your goals. If you’re concerned about server load, you can use CDN-level blocking. If you want to potentially increase your AI visibility, review current AI crawler user agents and allow only the specific bots that support your strategy.


Featured Image: BestForBest/Shutterstock

Google’s Mueller Explains ‘Page Indexed Without Content’ Error via @sejournal, @MattGSouthern

Google Search Advocate John Mueller responded to a question about the “Page Indexed without content” error in Search Console, explaining the issue typically stems from server or CDN blocking rather than JavaScript.

The exchange took place on Reddit after a user reported their homepage dropped from position 1 to position 15 following the error’s appearance.

What’s Happening?

Mueller clarified a common misconception about the cause of “Page Indexed without content” in Search Console.

Mueller wrote:

“Usually this means your server / CDN is blocking Google from receiving any content. This isn’t related to anything JavaScript. It’s usually a fairly low level block, sometimes based on Googlebot’s IP address, so it’ll probably be impossible to test from outside of the Search Console testing tools.”

The Reddit user had already attempted several diagnostic steps. They ran curl commands to fetch the page as Googlebot, checked for JavaScript blocking, and tested with Google’s Rich Results Test. Desktop inspection tools returned “Something went wrong” errors while mobile tools worked normally.

Mueller noted that standard external testing methods won’t catch these blocks.

He added:

“Also, this would mean that pages from your site will start dropping out of the index (soon, or already), so it’s a good idea to treat this as something urgent.”

The affected site uses Webflow as its CMS and Cloudflare as its CDN. The user reported the homepage had been indexing normally with no recent changes to the site.

Why This Matters

I’ve covered this type of problem repeatedly over the years. CDN and server configurations can inadvertently block Googlebot without affecting regular users or standard testing tools. The blocks often target specific IP ranges, which means curl tests and third-party crawlers won’t reproduce the problem.

I covered when Google first added “indexed without content” to the Index Coverage report. Google’s help documentation at the time noted the status means “for some reason Google could not read the content” and specified “this is not a case of robots.txt blocking.” The underlying cause is almost always something lower in the stack.

The Cloudflare detail caught my attention. I reported on a similar pattern when Mueller advised a site owner whose crawling stopped across multiple domains simultaneously. All affected sites used Cloudflare, and Mueller pointed to “shared infrastructure” as the likely culprit. The pattern here looks familiar.

More recently, I covered a Cloudflare outage in November that triggered 5xx spikes affecting crawling. That was a widespread incident. This case appears to be something more targeted, likely a bot protection rule or firewall setting that treats Googlebot’s IP addresses differently from other traffic.

Search Console’s URL Inspection tool and Live URL test remain the primary ways to identify these blocks. When those tools return errors while external tests pass, server-level blocking becomes the likely cause. Mueller made a similar point in August when advising on crawl rate drops, suggesting site owners “double-check what actually happened” and verify “if it was a CDN that actually blocked Googlebot.”

Looking Ahead

If you’re seeing the “Page Indexed without content” error, check the CDN and server configurations for rules that affect Googlebot’s IP ranges. Google publishes its crawler IP addresses, which can help identify whether security rules are targeting them.

The Search Console URL Inspection tool is the most reliable way to see what Google receives when crawling a page. External testing tools won’t catch IP-based blocks that only affect Google’s infrastructure.

For Cloudflare users specifically, check bot management settings, firewall rules, and any IP-based access controls. The configuration may have changed through automatic updates or new default settings rather than manual changes.

WordPress Meets Vibe Coding: White-Labeled Platform & API For Search-Ready AI Websites

This post was sponsored by 10Web. The opinions expressed in this article are the sponsor’s own.

Not long ago, building a website meant a discovery call, a proposal, a sitemap, and a few weeks of back and forth. Today, we go from “I need a website” to “Why isn’t it live yet?” People are getting used to typing a short prompt and seeing an entire site structure, design, and a first-draft of their site in minutes. That doesn’t replace all the strategy, UX, or growth work, but it changes expectations about how fast the first version should appear, and how teams work.

This shift puts pressure on everyone who sits between the user and the web: agencies, MSPs, hosting companies, domain registrars, and SaaS platforms. If your users can get an AI-generated site somewhere else in a few clicks, you better catch the wave or be forgotten.

That’s why the real competition is moving to those who control distribution and can embed an AI-native, white-label builder directly into products. WordPress still powers over 43% of all websites globally, and remains the default foundation for many of these distribution players.

Now that AI-native builders, reseller suites, and website builder APIs are available on top of WordPress, who will own that experience and the recurring revenue that comes with it.

AI & Vibe Coding Is Turning Speed-To-Launch Into a Baseline 

AI site builders and vibe coding tools have taught people a new habit: describe what you want, get a working draft of a site almost immediately.

Instead of filling out long briefs and waiting for mockups, users can:

  • Type or paste a business description,
  • Point to a few example sites,
  • Click generate,
  • And see a homepage, key inner pages, and placeholder copy appear in minutes.

For non-technical users, this is magic. For agencies and infrastructure providers, it’s a new kind of pressure. The baseline expectation has become seeing something live quickly and refining it afterward.

This demand is everywhere:

  • Small businesses want a site as soon as they buy a domain or sign up for SaaS.
  • Creators expect their website to follow them seamlessly from the tools they already use.
  • Teams inside larger organizations need landing pages and microsites created on demand, without long internal queues.

If you’re an agency, MSP, hosting provider, domain registrar, or SaaS platform, you’re now measured against that baseline, no matter what your stack was designed for. Bolting on a generic external builder isn’t enough. Users want websites inside the experience they trust and already pay you for, with your branding, your billing, and your support.

AI-native builders that are built directly into your stack are no longer a nice bonus but an essential part of your product.

With Vibe Coding Leveling The Field: What Is Your Differentiator? 

In this environment, the biggest advantage doesn’t belong to whoever ships the flashiest AI demo. It belongs to whoever owns the distribution channels:

  • Agencies and MSPs, the ground level players holding client relationships and trust.
  • Hosting and cloud providers where businesses park their infrastructure.
  • Domain registrars where the online journey starts.
  • SaaS platforms, already owning the critical data needed to reflect and sync with company websites.

These players already control the key moments when someone goes from thinking they need a website to taking action.

  • Buying a domain
  • Using a vertical SaaS product
  • Working with an MSP or agency retainer
  • Adding a new location, service, or product line

If, at those moments, the platform automatically provides an AI-generated, editable site under the same login, billing, and support, the choice of stack is made by default. Users simply stay with the builder that’s already built into the service or product they use.

This is why white-label builders, reseller suites, and website builder APIs matter. They give distribution owners the opportunity to:

  • Brand the website experience as their own
  • Decide on the underlying technology (e.g., AI-native WordPress)
  • Bundle sites with hosting, marketing, or other services
  • Keep the recurring revenue and data inside their ecosystem

In other words, as AI pushes the web toward instant presence, distribution owners who embed website creation into their existing flows become the gatekeepers of which tools, stacks, and platforms win.

How To Connect WordPress Development, SEO & Vibe Coding

For most distribution owners, WordPress is still the safest base to standardize on. It powers a huge share of the web, has a deep plugin and WooCommerce ecosystem, and a large talent pool, which makes it easier to run thousands of sites without being tied to a single vendor. Its open-source nature also allows full rebranding and custom flows, exactly what white-label providers need, while automated provisioning, multisite, and APIs make it a natural infrastructure layer for branded site creation at scale. The missing piece has been a truly AI-native, generation-first builder. The latest AI-powered WordPress tools are closing that gap and expanding what distribution owners can offer out of the box.

Use AI-Native WordPress & White Label Embeddable Solutions

Most of the visible WordPress innovation around AI and websites has happened in standalone AI builders or coding assistants, relying on scattered plugins and lightweight helpers. The CMS is solid, but the first version of a site is still mostly assembled by hand.

AI-native WordPress builders move AI into the core flow: from intent straight to a structured, production-ready WordPress site in one step. In 10Web’s case, Vibe for WordPress is the first to bring Vibe Coding to the market with a React front end and deep integrations with WordPress. As opposed to previous versions of the builder or other website builders working off of generic templates and content, Vibe for WordPress allows the customer to have unlimited freedom during and after website generation via chat based AI and using natural language.

For distribution owners, AI only matters if it is packaged in a way they can sell, support, and scale. At its core, the 10Web’s White Label solution is a fully white-labeled AI website builder and hosting environment that partners brand as their own, spanning the dashboard, onboarding flows, and even the WordPress admin experience.

Instead of sending customers to a third-party tool, partners work in a multi-tenant platform where they can:

  • Brand the entire experience (logo, colors, custom domain).
  • Provision and manage WordPress sites, hosting, and domains at scale.
  • Package plans, track usage and overages, and connect their own billing and SSO.

In practice, a telco, registrar, or SaaS platform can offer AI-built WordPress websites under its own brand without building an editor, a hosting stack, or a management console from scratch.

APIs and White-Label: Quickly Code New Sites Or Allow Your Clients To Feel In Control

There is one fine nuance, yet so important. Speed alone isn’t a deciding factor on who wins the next wave of web creation. Teams that can wire that speed directly into their distribution channels and workflows will be the first to the finish line.

The White label platforms and APIs are two sides of the same strategy. The reseller suite gives partners a turnkey, branded control center; the API lets them take the same capabilities and thread them through domain purchase flows, SaaS onboarding, or MSP client portals.

From there, partners can:

  • Generate sites and WooCommerce stores from prompts or templates.
  • Provision hosting, domains, and SSL, and manage backups and restore points via API.
  • Control plugins, templates, and vertical presets so each tenant or region gets a curated, governed stack.
  • Pull usage metrics, logs, and webhooks into their own analytics and billing layers.

For MSPs and agencies treating websites as a packaged, recurring service, see more predictable revenue and stickier client relationships. They bake “website included” into retainers, care plans, and bundles, using white-label reseller dashboard to keep everything under their own brand.

As for SaaS platform and vertical solutions, instead of just giving partners a branded dashboard, 10Web’s Website Builder API lets them embed AI-powered WordPress site creation and lifecycle management directly into their own products. At a high level, it’s a white-label AI builder you plug in via API so your users can create production-ready WordPress sites and stores in under a minute, without ever leaving your app.

In this model, when someone buys a domain, signs up for a SaaS tool, or comes under an MSP contract, they experience the AI website Builder as a built-in part of the product. And the distribution owner, armed with white-label and API tools, is the one who captures the recurring value of that relationship.

The Next Wave

WordPress remains the foundation distribution owners trust, the layer they know can scale from a single landing page to thousands of client sites. With 10Web’s  AI-native builder, reseller dashboard, and API, it isn’t playing catch-up anymore, but is quickly becoming the engine behind fast, governed, repeatable site creation.

For agencies, MSPs, cloud infrastructure providers, and SaaS platforms, that means they can sell websites as a packaged service. The winners of the next wave are the ones who wire AI-native, white-label WordPress into their distribution and turn “website included” into their default.

Unlock new revenue by selling AI. Websites, Hosting, AI Branding, AI Agents, SMB Tools, and your own services.


Image Credits

Featured Image: Image by 10Web. Used with permission.

Google AI Overviews: How To Measure Impressions & Track Visibility

AIO Is Reshaping Click Distribution On SERPs

AI Overviews change how clicks flow through search results. Position 1 organic results that previously captured 30-35% CTR might see rates drop to 15-20% when an AI Overview appears above them.

Industry observations indicate that AI Overviews appear 60-80% of the time for certain query types. For these keywords, traditional CTR models and traffic projections become meaningless. The entire click distribution curve shifts, but we lack the data to model it accurately.

Brands And Agencies Need To Know: How Often AIO Appears For Their Keywords

Knowing how often AI Overviews appear for your keywords can help guide your strategic planning.

Without this data, teams may optimize aimlessly, possibly focusing resources on keywords dominated by AI Overviews or missing chances where traditional SEO can perform better.

Check For Citations As A Metric

Being cited can enhance brand authority even without direct clicks, as people view your domain as a trusted source by Google.

Many domains with average traditional rankings lead in AI Overview citations. However, without citation data, sites may struggle to understand what they’re doing well.

How CTR Shifts When AIO Is Present

The impact on click-through rate can vary depending on the type of query and the format of the AI Overview.

To accurately model CTR, it’s helpful to understand:

  • Whether an AI Overview is present or not for each query.
  • The format of the overview (such as expanded, collapsed, or with sources).
  • Your citation status within the overview.

Unfortunately, Search Console doesn’t provide any of these data points.

Without Visibility, Client Reporting And Strategy Are Based On Guesswork

Currently, reporting relies on assumptions and observed correlations rather than direct measurements. Teams make educated guesses about the impact of AI Overview based on changes in CTR, but they can’t definitively prove cause and effect.

Without solid data, every choice we make is somewhat of a guess, and we miss out on the confidence that clear data can provide.

How To Build Your Own AIO Impressions Dashboard

One Approach: Manual SERP Checking

Since Google Search Console won’t show you AI Overview data, you’ll need to collect it yourself. The most straightforward approach is manual checking. Yes, literally searching each keyword and documenting what you see.

This method requires no technical skills or API access. Anyone with a spreadsheet and a browser can do it. But that accessibility comes with significant time investment and limitations. You’re becoming a human web scraper, manually recording data that should be available through GSC.

Here’s exactly how to track AI Overviews manually:

Step 1: Set Up Your Tracking Infrastructure

  • Create a Google Sheet with columns for: Keyword, Date Checked, Location, Device Type, AI Overview Present (Y/N), AI Overview Expanded (Y/N), Your Site Cited (Y/N), Competitor Citations (list), Screenshot URL.
  • Build a second sheet for historical tracking with the same columns plus Week Number.
  • Create a third sheet for CTR correlation using GSC data exports.

Step 2: Configure Your Browser For Consistent Results

  • Open Chrome in incognito mode.
  • Install a VPN if tracking multiple locations (you’ll need to clear cookies and switch locations between each check).
  • Set up a screenshot tool that captures full page length.
  • Disable any ad blockers or extensions that might alter SERP display.

Step 3: Execute Weekly Checks (Budget 2-3 Minutes Per Keyword)

  • Search your keyword in incognito.
  • Wait for the page to fully load (AI Overviews sometimes load one to two seconds after initial results).
  • Check if AI Overview appears – note that some are collapsed by default.
  • If collapsed, click Show more to expand.
  • Count and document all cited sources.
  • Take a full-page screenshot.
  • Upload a screenshot to cloud storage and add a link to the spreadsheet.
  • Clear all cookies and cache before the next search.

Step 4: Handle Location-specific Searches

  • Close all browser windows.
  • Connect to VPN for target location.
  • Verify IP location using whatismyipaddress.com.
  • Open a new incognito window.
  • Add “&gl=us&hl=en” parameters (adjust country/language codes as needed).
  • Repeat Step 3 for each keyword.
  • Disconnect VPN and repeat for the next location.

Step 5: Process And Analyze Your Data

  • Export last week’s GSC data (wait two to three days for data to be complete).
  • Match keywords between your tracking sheet and GSC export using VLOOKUP.
  • Calculate AI Overview presence rate: COUNT(IF(D:D=”Y”))/COUNTA(D:D)
  • Calculate citation rate: COUNT(IF(F:F=”Y”))/COUNT(IF(D:D=”Y”))
  • Compare the average CTR for keywords with vs. without AI Overviews.
  • Create pivot tables to identify patterns by keyword category.

Step 6: Maintain Data Quality

  • Re-check 10% of keywords to verify consistency.
  • Document any SERP layout changes that might affect tracking.
  • Archive screenshots weekly (they’ll eat up storage quickly).
  • Update your VPN locations if Google starts detecting and blocking them.

For 100 keywords across three locations, this process takes approximately 15 hours per week.

The Easy Way: Pull This Data With An API

If ~15 hours a week of manual SERP checks isn’t realistic, automate it. An API call gives you the same AIO signal in seconds, on a schedule, and without human error. The tradeoff is a little setup and usage costs, but once you’re tracking ~50+ keywords, automation is cheaper than people.

Here’s the flow:

Step 1: Set Up Your API Access

  • Sign up for SerpApi (free tier includes 250 searches/month).
  • Get your API key from the dashboard and store it securely (env var, not in screenshots).
  • Install the client library for your preferred language.

Step 2, Easy Version: Verify It Works (No Code)

Paste this into your browser to pull only the AI Overview for a test query:

https://serpapi.com/search.json?engine=google&q=best+laptop+2026&location=United+States&json_restrictor=ai_overview&api_key=YOUR_API_KEY

If Google returns a page_token instead of the full text, run this second request:

https://serpapi.com/search.json?engine=google_ai_overview&page_token=PAGE_TOKEN&api_key=YOUR_API_KEY
  • Replace YOUR_API_KEY with your key.
  • Replace PAGE_TOKEN with the value from the first response.
  • Replace spaces in queries and locations with +.

Step 2, Low-Code Version

If you don’t want to write code, you can call this from Google Sheets (see the tutorial), Make, or n8n and log three fields per keyword: AIO present (true/false), AIO position, and AIO sources.

No matter which option you choose, the:

  • Total setup time: two to three hours.
  • Ongoing time: five minutes weekly to review results.

What Data Becomes Available

The API returns comprehensive AI Overview data that GSC doesn’t provide:

  • Presence detection: Boolean flag for AI Overview appearance.
  • Content extraction: Full AI-generated text.
  • Citation tracking: All source URLs with titles and snippets.
  • Positioning data: Where the AI Overview appears on page.
  • Interactive elements: Follow-up questions and expandable sections.

This structured data integrates directly into existing SEO workflows. Export to Google Sheets for quick analysis, push to BigQuery for historical tracking, or feed into dashboard tools for client reporting.

Demo Tool: Building An AIO Reporting Tool

Understanding The Data Pipeline

Whether you build your own tracker or use existing tools, the data pipeline follows this pattern:

  • Input: Your keyword list (from GSC, rank trackers, or keyword research).
  • Collection: Retrieve SERP data (manually or via API).
  • Processing: Extract AI Overview information.
  • Storage: Save to database or spreadsheet.
  • Analysis: Calculate metrics and identify patterns.

Let’s walk through implementing this pipeline.

You Need: Your Keyword List

Start with a prioritized keyword set.

Include categorization to identify AI Overview patterns by intent type. Informational queries typically show higher AI Overview rates than navigational ones.

Step 1: Call SerpApi To Detect AIO blocks

For manual tracking, you’d check each SERP:

  • Individually. (This tutorial takes 2 – 3 minutes per manual check.)
  • Instantly. (This returns structured data instantly.)

Step 2: Store Results In Sheets, BigQuery, Or A Database

View the full tutorial for:

Step 3: Report On KPIs

Calculate the following key metrics from your collected data:

  • AI Overview Presence Rate.
  • Citation Success Rate.
  • CTR Impact Analysis.

Combine with GSC data to measure CTR differences between keywords with and without AI Overviews.

These metrics provide the visibility GSC lacks, enabling data-driven optimization decisions.

Clear, transparent ROI reporting for clients

With AI Overview tracking data, you can provide clients with concrete answers about their search performance.

Instead of vague statements, you can present specific metrics, such as: “AI Overviews appear for 47% of your tracked keywords, with your citation rate at 23% compared to your main competitor’s 31%.”

This transparency transforms client relationships. When they ask why impressions increased 40% but clicks only grew 5%, you can show them exactly how many queries now trigger AI Overviews above their organic listings.

More importantly, this data justifies strategic pivots and budget allocations. If AI Overviews dominate your client’s industry, you can make the case for content optimization targeting AI citation.

Early Detection Of AIO Volatility In Your Industry

Google’s AI Overview rollout is uneven, occurring in waves that test different industries and query types at different times.

Without proper tracking, you might not notice these updates for weeks or months, missing crucial optimization opportunities while competitors adapt.

Continuous monitoring of AI Overviews transforms you into an early warning system for your clients or organization.

Data-backed Strategy To Optimize For AIO Citations

By carefully tracking your content, you’ll quickly notice patterns, such as content types that consistently earn citations.

The data also reveals competitive advantages. For example, traditional ranking factors don’t always predict whether a page will be cited in an AI Overview. Sometimes, the fifth-ranked page gets consistently cited, while the top result is overlooked.

Additionally, tracking helps you understand how citations relate to your business metrics. You might find that being cited in AI Overviews improves your brand visibility and direct traffic over time, even if those citations don’t result in immediate clicks.

Stop Waiting For GSC To Provide Visibility – It May Never Arrive

Google has shown no indication of adding AI Overview filtering to Search Console. The API roadmap doesn’t mention it. Waiting for official support means flying blind indefinitely.

Start Testing SerpApi’s Google AI Overview API Today

If manual tracking isn’t sustainable, we offer a free tier with 250 searches/month so you can validate your pipeline. For scale, our published caps are clear: 20% of plan volume per hour on plans under 1M/month, and 100,000 + 1% of plan volume per hour on plans ≥1M/month.

We also support enterprise plans up to 100M searches/month. Same production infrastructure, no setup.

Build Your Own AIO Analytics Dashboard And Give Your Team Or Clients The Insights They Need

Whether you choose manual tracking, build your own scraping solution, or use an existing API, the important thing is to start measuring. Every day without AI Overview visibility is a day of missed optimization opportunities.

The tools and methods exist. The patterns are identifiable. You just need to implement tracking that fills the gap Google won’t address.

Get started here →

For those interested in the automated approach, access SerpApi’s documentation and test the playground to see what data becomes available. For manual trackers, download our spreadsheet template to begin tracking immediately.

Cloudflare Outage Triggers 5xx Spikes: What It Means For SEO via @sejournal, @MattGSouthern

A Cloudflare incident is returning 5xx responses for many sites and apps that sit behind its network, which means users and crawlers may be running into the same errors.

From an SEO point of view, this kind of outage often looks worse than it is. Short bursts of 5xx errors usually affect crawl behavior before they touch long-term rankings, but there are some details worth paying attention to.

What You’re Likely Seeing

Sites that rely on Cloudflare as a CDN or reverse proxy may currently be serving generic “500 internal server error” pages or failing to load at all. In practice, everything in that family of responses is treated as a server error.

If Googlebot happens to crawl while the incident is ongoing, it will record the same 5xx responses that users see. You may not notice anything inside Search Console immediately, but over the next few days you could see a spike in server errors, a dip in crawl activity, or both.

Keep in mind that Search Console data is rarely real-time and often lags by roughly 48 hours. A flat line in GSC today could mean the report hasn’t caught up yet. If you need to confirm that Googlebot is encountering errors right now, you will need to check your raw server access logs.

This can feel like a ranking emergency. It helps to understand how Google has described its handling of temporary server problems in the past, and what Google representatives are saying today.

How Google Handles Short 5xx Spikes

Google groups 5xx responses as signs that a server is overloaded or unavailable. According to Google’s Search Central documentation on HTTP status codes, 5xx and 429 errors prompt crawlers to temporarily slow down, and URLs that continue to return server errors can eventually be dropped from the index if the issue remains unresolved.

Google’s “How To Deal With Planned Site Downtime” blog post gives similar guidance for maintenance windows, recommending a 503 status code for temporary downtime and noting that long-lasting 503 responses can be treated as a sign that content is no longer available.

In a recent Bluesky post, Google Search Advocate John Mueller reinforced the same message in plainer language. Mueller wrote:

“Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.”

He added:

“If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.”

Taken together, the documentation and Mueller’s comments draw a fairly clear line.

Short downtime is usually not a major ranking problem. Already indexed pages tend to stay in the index for a while, even if they briefly return errors. When availability returns to normal, crawling ramps back up and search results generally settle.

The picture changes when server errors become a pattern. If Googlebot sees 5xx responses for an extended period, it can start treating URLs as effectively gone. At that point, pages may drop from the index until crawlers see stable, successful responses again, and recovery can take longer.

The practical takeaway is that a one-off infrastructure incident is mostly a crawl and reliability concern. Lasting SEO issues tend to appear when errors linger well beyond the initial outage window.

See additional guidance from Google regarding 5xx errors:

Analytics & PPC Reporting Gaps

For many sites, Cloudflare sits in front of more than just HTML pages. Consent banners, tag managers, and third-party scripts used for analytics and advertising may all depend on services that run through Cloudflare.

If your consent management platform or tag manager was slow or unavailable during the outage, that can show up later as gaps in GA4 and ad platform reporting. Consent events may not have fired, tags may have timed out, and some sessions or conversions may not have been recorded at all.

When you review performance, you might see a short cliff in GA4 traffic, a drop in reported conversions in Google Ads or other platforms, or both. In many cases, that will reflect missing data rather than a real collapse in demand.

It’s safer to annotate today’s incident in your analytics and media reports and treat it as a tracking gap before you start reacting with bid changes or budget shifts based on a few hours of noisy numbers.

What To Do If You Were Hit

If you believe you’re affected by today’s outage, start by confirming that the problem is really tied to Cloudflare and not to your origin server or application code. Check your own uptime monitoring and any status messages from Cloudflare or your host so you know where to direct engineering effort.

Next, record the timing. Note when you first saw 5xx errors and when things returned to normal. Adding an annotation in your analytics, Search Console, and media reporting makes it much easier to explain any traffic or conversion drops when you review performance later.

Over the coming days, keep an eye on the Crawl Stats Report and index coverage in Search Console, along with your own server logs. You’re looking for confirmation that crawl activity returns to its usual pattern once the incident is over, and that server error rates drop back to baseline. If the graphs settle, you can treat the outage as a contained event.

If, instead, you continue to see elevated 5xx responses after Cloudflare reports the issue as resolved, it’s safer to treat the situation as a site-specific problem.

What you generally do not need to do is change content, internal linking, or on-page SEO purely in response to a short Cloudflare outage. Restoring stability is the priority.

Finally, resist the urge to hit ‘Validate Fix’ in Search Console the moment the site comes back online. If you trigger validation while the connection is still intermittent, the check will fail, and you will have to wait for the cycle to reset. It is safer to wait until the status page says ‘Resolved’ for a full 24 hours before validating.

Why This Matters

Incidents like this one are a reminder that search visibility is tied to reliability as much as relevance. When a provider in the middle of your stack has trouble, it can quickly look like a sudden drop, even when the root cause is outside your site.

Knowing how Google handles temporary 5xx spikes and how they influence analytics and PPC reports can help you communicate better with your clients and stakeholders. It allows you to set realistic expectations and recognize when an outage has persisted long enough to warrant serious attention.

Looking Ahead

Once Cloudflare closes out its investigation, the main thing to watch is whether your crawl, error, and conversion metrics return to normal. If they do, this morning’s 5xx spike is likely to be a footnote in your reporting rather than a turning point in your organic or paid performance.