Jun 2 2026
Microsoft Web IQ Gives AI Agents Bing Grounding APIs via @sejournal, @MattGSouthern

Microsoft announced Web IQ, a set of grounding APIs that let AI agents pull information from Bing’s search index.

The company calls Web IQ “a search engine for AI systems.” Where Bing helps people find web pages, Web IQ helps AI agents find information they can use while reasoning through a task.

What Web IQ Does

Web IQ uses a rebuilt retrieval stack based on the Bing index, redesigning how content is indexed, ranked, and selected. AI agents search repeatedly under tight time constraints across multiple steps.

The API returns passages and ‘structured evidence objects’ instead of full web pages, so AI models receive only the useful parts of a page. Every token an AI model processes costs money and adds latency, so fewer tokens with better information means cheaper and faster answers.

Microsoft summarizes it as “fewer tokens in, better answers out, lower cost per call.”

Performance Claims

Microsoft uses GDSAT (grounding satisfaction) to measure if info is fresh and trustworthy. They claim Web IQ scores higher than competitors based on 3,000 sample queries.

The company reports sub-165ms response times at P95, nearly 2.5 times faster than competitors, based on tests across five data centers.

On token efficiency, Microsoft reports that Web IQ delivers the same quality with fewer tokens as the volume of results increases.

Publisher Controls

Web IQ follows the same robots exclusion rules and publisher preferences that Bing already honors. The company is also working with the IETF and other industry groups on standards for how AI systems access web content.

Technical Details

Web IQ uses Microsoft’s open-sourced embedding model to find relevant content and additional models to rank and select passages.

According to the announcement, these models are trained for how they’ll be used inside AI reasoning, not for standalone benchmark scores.

For fast search at scale, the system extends DiskANN, Microsoft’s technology for searching large indexes without loading everything into memory.

Why This Matters

Microsoft has been building toward this. Bing Webmaster Tools added AI citation data in February, mapped grounding queries to cited pages in March, and previewed Citation Share at SEO Week. Those tools show publishers how AI systems use their content, and Web IQ is the other side of that. It’s what AI systems would use to pull the content in the first place.

In Web IQ, information is returned as passages rather than full pages. What makes a page rank well in traditional search and what makes a passage useful for grounding may not overlap, as Microsoft’s own grounding framework post described earlier this year.

Looking Ahead

Web IQ is accepting expressions of interest but hasn’t announced general availability, pricing, or which AI platforms will use it. Microsoft hasn’t said whether existing Copilot or Bing Chat grounding uses Web IQ, or whether Web IQ is separate from those systems.

Ecommerce MGMT 0 Comments
May 26 2026
Machine-First Architecture: How To Build Websites Machines Can Identify, Read, Cite & Use via @sejournal, @slobodanmanic

In the late 2000s, “mobile-first” emerged as a design discipline. The argument was a single sentence: don’t design for the big screen and squeeze it down. Start with the small screen, the harder constraint, the one that forces you to figure out what actually matters. If it works on a phone, it works everywhere.

Google leaned in early. By February 2010, Eric Schmidt was telling Mobile World Congress that Google’s strategy was “Mobile First in everything.” In April 2015, the Mobilegeddon update penalized non-mobile-friendly websites at scale. In October 2016, StatCounter reported mobile traffic surpassing desktop globally for the first time. A month later, Google announced mobile-first indexing. By October 2023, that migration was complete.

The web is now standing at the same kind of inflection point. Except the harder constraint isn’t a small screen. It’s no screen at all. It’s a machine.

The approach I use, Machine-First Architecture, is a full-stack methodology covering the entire arc of how machines now interact with a brand. It runs from how an organization is identified and resolved across the web, to how a website’s pages expose their data, to how content is consumed and cited, to how an autonomous agent completes a transaction on the website itself. Four pillars, in a specific order: Identity, Structure, Content, Interaction. The order matters. Each pillar depends on the one before it.

This is a website architecture discipline, not a content optimization playbook. Content is just one of four pillars. Most existing AI-search guidance, including frameworks I deeply respect, sits inside that single pillar. Machine-First Architecture extends upstream to organizational identity and downstream to autonomous agent action because that is where the actual work now is.

Last month, I outlined five layers the technical SEO audit needs to add for AI search. That piece described what to check on a website that already exists. Machine-First Architecture is the build framework the audit assumes: the architectural sequence you follow before any audit, on a website you are designing or rebuilding from the ground up. The audit catches gaps. The architecture prevents them. Reading the two together is the point: the build sequence here, the audit checklist there.

The whole journey has to be covered, and that is the part that matters most. The agentic journey is end-to-end: a machine has to identify your brand, parse your website’s structure, evaluate your content, and complete an action on your website. If any one of those steps fails, the whole chain fails. Excellent content cannot save a website with broken identity, because the machine never resolves the right entity to attribute the content to. Strong identity does nothing if the website’s structure hides the data behind JavaScript a crawler will not run. And both of those are wasted if an agent arrives ready to transact and finds a checkout flow it cannot navigate without a human.

It is important to note that machine-first does not mean human-last. Designing for the most constrained consumer (a machine that cannot interpret visual layouts, guess at meaning, or recover from ambiguity) creates a foundation that serves all visitors more effectively. Mobile-first didn’t make desktop worse. It made desktop better by prioritizing what really matters. Machine-first does the same thing for human consumers.

This is the reference version of the framework. What each pillar covers, what to build, what fails when it is missing, and what real protocol infrastructure now backs each one.

Pillar 1: Identity. Can Machines Unambiguously Identify Who You Are?

Identity must come first because AI systems cannot evaluate, recommend, or transact with a brand they cannot confidently resolve.

Google’s Knowledge Graph holds tens of billions of entities and well over a trillion facts about them, with E-E-A-T credibility signals applied at the person-entity level. AI systems consolidate brand identity by reading multiple external platforms in parallel and reconciling what they find. When your website says “AI consultancy,” your LinkedIn says “digital agency,” and your Google Business Profile says “IT services,” models either average those signals into something vague or lose confidence in the entity altogether.

Canonical Definition

A canonical definition is a single, structured, machine-readable document that defines what an organization is in fields rather than paragraphs. Think of it as your brand’s API documentation. Every bio, directory listing, schema block, and social profile description should trace back to this one canonical source.

Entity Relationships

When an AI system answers “who are the leading consultants in this space,” the model traverses connections between entities: founders, clients, industry categories, technologies, publications. The machine-first approach means actively defining and publishing those relationships as structured data, rather than leaving them implicit in blog posts.

Ecosystem Mapping

Map every platform where your brand exists or should exist. Industry directories, review platforms, podcast directories, GitHub profiles, marketplace listings, data aggregators. Each platform exposes data to machines differently. Optimize each platform’s specific structured data format rather than copy-pasting the same bio across all of them.

Version Control

Treat your canonical definition as a versioned document. When identity changes, propagate that change across every platform in your ecosystem map. Machines synthesize identity continuously, and staleness in any one source can degrade the overall picture.

Research by The Digital Bloom from December 2025 found that brands mentioned on four or more platforms are 2.8 times more likely to appear in ChatGPT responses. The architectural condition that makes that compounding effect work, in my experience, is that the platforms tell the same story, which is what the Identity pillar is built to enforce.

A note on scope. This pillar is about the identity of the brand the AI system is trying to recognize. It is not about the cryptographic identity of the AI agent accessing the website. Both matter, but they are different problems.

Output of this pillar:

  • A structured identity document serving as the single source of truth.
  • A map of every platform in your digital ecosystem.
  • A process for keeping all platforms aligned over time.

Pillar 2: Structure. Can Machines Extract Your Information?

Structure inverts the traditional web design process. Define the data model first, then wrap the design around the data.

Most websites are designed to look good to humans, with critical information locked inside visual layouts, JavaScript interactions, and design patterns that machines cannot parse. When an AI agent lands on a product page, it needs to extract the price, specifications, and availability programmatically. Structure is what makes that extraction work.

Structure overlaps with classical technical SEO and modern front-end engineering, but it is neither. Technical SEO has historically focused on what a single rendered page exposes to one crawler. Front-end engineering has focused on how that page is delivered and made interactive for human eyes. Structure, as a pillar of Machine-First Architecture, is upstream of both. It asks what data each page type exists to expose, before either the technical SEO audit or the front-end build begins. The audit checks whether the data is reachable. The architecture decides what data is there to be reached.

Data Models Before Page Designs

Before wireframing a page, define the discrete, extractable pieces of information that page must contain. The question changes from “what should this page look like?” to “what data does this page need to expose?” The page design wraps around the data model, instead of forcing the data model to conform to the design. This is the inversion that distinguishes architecture from audit. An audit can tell you whether your product page exposes price, availability, and specifications. Only the architecture step decides those are the four facts the page exists to express in the first place.

Information Hierarchy For Machines

Machine information hierarchy is structural, not visual. Machines read heading level, schema markup, semantic HTML, and position on the page, not font size, color, or visual weight. Architecturally, this means deciding what goes in the first content block of every page type before deciding how the page looks.

Relationship Architecture

This is where Machine-First Architecture diverges most sharply from how websites are traditionally built. The conventional process designs and ships pages one at a time, with the relationships between them inferred later from navigation menus and internal links. That is backward. Machines need to understand how pages relate to each other before they understand any single page: product taxonomies, service hierarchies, content-to-offering mappings, parent-child structures. Declare those connections explicitly through internal linking patterns, breadcrumb structures, and schema that names the hierarchical relationships directly. The test: Could a machine, starting from your homepage, construct a complete and accurate map of everything you offer by following structured, declared relationships? Not by guessing from menu labels. By traversing connections you have explicitly published.

One more decision belongs in this pillar: rendering. Critical data has to be present in the initial HTML response, before any client-side JavaScript runs. Build a JavaScript-heavy website where prices, specifications, and availability load after the page renders, and that data is locked away from every crawler that doesn’t execute JavaScript. Retrofitting a client-rendered SPA into something that serves data in static HTML is a very expensive failure mode. I broke down which AI crawlers render JavaScript and which ones don’t in “The Technical SEO Audit Needs A New Layer” if you want the specifics.

Output of this pillar:

  • A data model for every key page type, defining exactly what machine-readable information each page contains.
  • A relationship architecture connecting all pages.
  • A rendering strategy ensuring critical data is accessible regardless of how the page is processed.

Do not start designing pages until this work is done. The rendered page is one possible output of the data model. AI search results, voice answers, agent tool calls, and chat citations are other outputs the same data model has to serve. If the design comes first, the data model is whatever the design happened to support, which is rarely what every machine consumer needs.

Pillar 3: Content. Will Machines Rely On What You Are Saying?

Content is the pillar most existing AI-search research already targets. Kevin Indig‘s Growth Memo, Duane Forrester‘s Substack, Ramon Eijkemans’ utility-writing framework, and the ongoing work coming out of SEO Week and the BrightonSEO research community have produced rigorous data on how AI systems evaluate content. I lean on their work in this pillar more than I do in the others, and so should you.

The discipline of writing for AI extraction (answer-first writing, content extractability, citable specificity, content position) is something I get into in detail in “The Technical SEO Audit Needs A New Layer,” and the practitioners I named go deeper still. What Machine-First Architecture adds to that discipline is three architectural decisions that determine whether any of the writing-side work can succeed at all. They are: how authorship is structurally established, how time is signaled, and how the page is composed as modular knowledge units rather than a monolithic narrative.

Authorship And Attribution

AI systems evaluate authorship against the broader knowledge graph when deciding whether to cite a source. Machine-first content makes authorship explicit and structured: who wrote this, what their credentials are, where else they have published. Connected to the knowledge graph through schema markup, with sameAs links to verified profiles, with the author entity itself defined in the canonical identity document established by the Identity Pillar. This is where Identity and Content compose: the author entity referenced here is the same entity defined upstream. Authorship buried in a footer bio is invisible to that compounding effect.

Temporal Signaling

AI systems weigh recency heavily. A 2024 guide loses ground to a 2026 article on the same topic, regardless of objective quality. The distinction runs deeper than ranking. As Duane Forrester wrote, pre-cutoff and post-cutoff content occupy different systems inside the same model. Pre-cutoff content is presented confidently and without attribution. Post-cutoff content arrives with hedging language and citations. The architectural move is this: declare when specific claims were true, what data they are based on, and what has changed since original publication, at a granularity finer than the page’s publication date. AI systems can then evaluate the freshness of individual claims rather than treating the whole page as one timestamp.

Knowledge Modularity

Retrieval systems extract specific claims, answers, and data points. They do not consume content as continuous narrative. Long documents have a well-documented middle-section problem: Language models attend most strongly to the beginning and end of a document and lose fidelity in the middle. Self-contained sections are how content survives that effect. The architectural move is to design content as collections of modular knowledge units rather than monolithic articles. Each section has its own clear scope, its own question, its own supporting evidence. The page tells a complete story where each component functions independently when extracted. This is a composition decision made at the architecture level, not a writing decision made at the draft step.

Output of this pillar: a content framework where:

  • Authorship is structurally connected to your identity layer.
  • Time is declared at claim granularity.
  • The page is composed as modular knowledge units that function independently when retrieved.

Pillar 4: Interaction. Can Machines Act On Your Website Autonomously?

Interaction is the pillar where most existing AI-search frameworks stop. Visibility and citation work covers the first half of the journey: The machine finds and reads you. Accessibility work covers a different problem entirely: a human user with assistive technology making decisions in real time. The pillar that nobody else is finishing is the part where an autonomous agent has to do something on the website on behalf of a real person, with real money, with no human in the loop at the moment of action.

Leaving this last step unfinished is the costliest gap in the journey. An agent that can find your website, parse it, and decide it is the right answer will still abandon if it cannot complete the action it came to perform. That failure will be silent. You never see it in your analytics or your error log, the customer never tells you their agent gave up, and the next agent visit goes to a competitor whose interaction layer works. The full agentic journey is identification through completion, and the framework only delivers compounding value if every pillar holds.

The distinction from accessibility is important. Accessibility assumes a human is still in control: A screen reader translates the page for a person who makes decisions, interprets ambiguity, and recovers from errors. Machine interaction has no human in the loop at the point of action. The agent decides, acts, and verifies on its own.

Most of the eye-catching numbers in trade press right now (393% year-over-year jumps in AI-referred traffic, conversion lifts of 42%, peaks above 1,000% in the December holiday window) measure human traffic that came from AI-powered browsers and AI search results, not autonomous agent activity on the website. A person used ChatGPT or Atlas or Comet to find your website, then clicked through and shopped themselves. That is a real and growing share of website traffic, but it is the visibility-and-citation half of the journey, not the interaction half.

However, the logical next step for that same traffic is the machine also doing the action. The user who today asks ChatGPT to recommend a product and then clicks through to buy it will, increasingly, ask ChatGPT to buy it. The user who today asks Comet to compare hotels and then completes the booking themselves will, increasingly, hand the booking off to the agent. Each step delegates more of the journey to the machine. The Interaction pillar is the layer that has to be ready before that delegation becomes the default. That layer is currently developing, but moving very fast.

Every major AI vendor running the citation layer is also building the agent layer at the same pace, often faster. The companies that decide whether to cite your website are the same companies that decide where their agents try to act.

  • OpenAI runs ChatGPT alongside the Atlas browser, with built-in agent mode (formerly the standalone Operator product, integrated into ChatGPT in mid-2025).
  • Google folded Project Mariner into Gemini Agent and Chrome’s auto-browse capability in May 2026, and operates the Google-Agent fetcher for AI systems acting on user queries.
  • Anthropic pairs Claude with computer-use capability and the Claude-User crawler.
  • Perplexity has both its answer engine and the Comet browser.
  • Microsoft built Copilot Mode and Agent Mode into Edge for multi-step automation.

Treating AI as a pure distribution channel (optimizing for citation, stopping at “be visible in the answer”) is the most dangerous position in this discipline. It assumes the journey ends at the citation, which the vendors building the system have already publicly committed it does not. The citation and agent layers are rolling out on overlapping timelines from the same companies. The website architecture has to be ready for both.

The protocol stack supporting agent-side interaction has crystallized over the last twelve months.

  • Model Context Protocol (MCP): agent-to-tool communication. An inaugural project of the Agentic AI Foundation under the Linux Foundation.
  • A2A: agent-to-agent coordination. A separate Linux Foundation project.
  • WebMCP: agent-to-website interaction. A W3C Community Group draft.
  • Agentic Commerce Protocol (ACP): agent-initiated commerce. Co-developed by OpenAI and Stripe and launched inside ChatGPT in 2025. OpenAI scaled native in-ChatGPT checkout back in early 2026 after low adoption, and ACP now powers purchases through merchant apps integrated into ChatGPT rather than native checkout. The protocol continues, the deployment model is still being figured out.
  • Universal Commerce Protocol (UCP): agent-to-merchant commerce. Developed by Google with Shopify, Etsy, Wayfair, Target, and Walmart, and endorsed by 20+ partners across retail, payments, and processors (Stripe, Visa, Mastercard, American Express, Best Buy, Macy’s, The Home Depot, Zalando, and more). Announced at NRF in January 2026. Shopify’s implementation includes UCP-compliant MCP servers covering storefront browsing, customer account access, and developer tooling so agents can browse, compare, and place orders without screen-scraping.
  • Visa’s Trusted Agent Protocol: cryptographic identity for agent-initiated transactions. In production.

Autonomous agent transactions are not the dominant share of website traffic today, but the infrastructure is in place, the first flows are live, and the websites that wait until traffic forces the issue will be the ones rebuilding under pressure rather than designing into it. Interaction is the build-now-for-the-near-future pillar.

Discoverability Of Actions

A human can tell that a button is clickable through visual design. An AI agent has no such intuition. It needs a programmatic action manifest: Structured declarations of what actions are available on each page, what inputs those actions require, and what outcomes they produce. Schema.org actions provide one path; WebMCP provides another. Every page must answer “what can a machine do here?” as clearly as it answers “what can a human see here?”

Predictable Outcomes

Every action must return a machine-readable response confirming what happened, what changed, and what the next available actions are. An agent adding an item to a cart needs structured state confirmation: The item was added, the cart now contains three items, the total is this amount, the next available action is checkout or continued browsing. Design the state communication layer before the visual feedback layer.

Workflow Continuity

A human navigating a multi-step checkout maintains context mentally. An agent needs that context exposed as structured data: current step, prior decisions, remaining steps, required inputs, and the ability to revise without losing progress.

Error Recovery

Treat errors as structured branching points, not dead ends. When an agent encounters an out-of-stock item, “sorry, something went wrong” is useless. The error response must include structured data: The item is unavailable in size M, available sizes are S, L, and XL, a similar product is available in size M. Every error needs to be a decision point the agent can navigate without human intervention.

Trust And Verification

Humans rely on visual trust signals: padlock icons, brand recognition, professional design. Agents acting on behalf of humans with real money need machine-verifiable trust data: structured, verifiable transaction terms covering pricing, return policies, merchant verification, and guarantees that can be evaluated programmatically before committing. Visa’s Trusted Agent Protocol adds cryptographic proof-of-identity to agent-initiated transactions. The Agentic Commerce Protocol provides the merchant-side payment specification that agent checkouts run on.

Agent Policies And Permissions

When agents visit your website, you need a way to communicate what they are allowed to do. Browse only, or transact? Compare prices? Identify themselves? Rate limits? Standards work here is moving fast and not yet settled. New drafts are published every few weeks across IETF, W3C, and vendor working groups. The architectural need stays the same regardless of which draft wins: a programmatic way to declare what agents can do on your website, before they try to do it.

Output of this pillar: a functional map of every key action on the website, designed as:

  • Machine-navigable pathways with predictable outcomes.
  • Structured error recovery.
  • Verifiable trust signals.
  • Explicit agent policies.

The human visual experience is an enhancement layer on top of this.

The Four Pillars Are Sequential, Not Parallel

Build order matters. Identity first, Structure second, Content third, Interaction last.

You cannot have machine-readable Content without resolved Identity. The authorship principle (who wrote this, what their credentials are, what entities they connect to) depends on the canonical definition that Identity establishes.

You cannot expose Interaction without underlying Structure. An agent cannot complete a checkout flow on a page where the data model was never defined. The action manifest the agent reads is built on the same structural foundation that exposes price, specifications, and availability.

You cannot fix Interaction by patching it on at the end. Websites that try this end up with disconnected JavaScript widgets that simulate machine-readability without actually delivering it. Agents detect the gap, abandon the task, and leave no trace in your analytics.

Build Identity first. Layer Structure on top of it. Build Content into the Structure. Add Interaction as the operational layer once the first three are in place. Each pillar makes the next one possible.

Where To Start: One Action Per Pillar

A practical architecture move per pillar. None of these are audit checks. They are decisions you make before any audit becomes useful.

Identity. Write your canonical definition as fields, not paragraphs. What you do, who you do it for, where you operate, what makes you credible, who the key people are, what entities you connect to. Make this the source of truth that every bio, schema block, and platform listing derives from. Then Google your business name and compare what comes back against that definition. Every platform that tells a different story is a leak in your identity that the canonical document needs to resolve.

Structure. Pick your three most important page types: homepage, primary product or service, primary content. For each, list the discrete facts the page exists to expose, in priority order, before any consideration of layout or design. If you cannot list those facts, the page is being designed before the data model exists, which is the inversion you should aim to prevent.

Content. Pick the three pages most likely to be cited by AI systems. For each, establish two architectural connections: the author entity, schema-linked to the canonical identity document established by the Identity Pillar, and granular temporal signaling on specific claims, declaring when each was true and what data underlies it. The audit will catch whether the content reads well. The architecture decides whether the content is structurally connected to your identity and dated at the claim level.

Interaction. Try to complete a core action on your website (buying something, booking something, submitting a form) using only a screen reader. If you cannot get through the flow, neither can an agent. And agents do not have the patience to figure it out. They move on to a competitor.

Where Machine-First Architecture Fits Among SEO, GEO, And Accessibility

Machine-First Architecture is deliberately broader in scope than the existing AI-search guidance most practitioners are working with. Most frameworks in this space focus on a single slice of the journey: visibility, citation, content optimization, retrieval mechanics. Those are real disciplines, and they are necessary work. Machine-First Architecture is built one altitude above them: the architectural methodology that determines whether any of those tactics can land at all, plus the autonomous-interaction layer the others do not address.

Look at the scope mapping. SEO has historically covered Structure, plus parts of Identity through schema. Generative Engine Optimization covers Content, plus parts of Structure for retrieval. Accessibility covers parts of Structure and parts of Interaction, but only for human-assisted access. Both organizational Identity and autonomous-agent Interaction sit outside the primary scope of every existing discipline. Machine-First Architecture is what sits at the union.

The framework’s scope is bounded by what AI vendors and standards bodies are actively building toward consuming, not by speculation about what future AI might want. Identity protocols are landing, with Knowledge Graph consolidation already in production and verifiable-identity standards moving through W3C. Structural data extraction is mature, with all major AI crawlers parsing JSON-LD and semantic HTML. Content evaluation has documented retrieval mechanisms across position-based citation, authorship cross-referencing, and recency weighting. Interaction protocols are crystallizing as I write this. The four pillars don’t describe what to build for an imagined future. They describe what to build for the demand surface that already exists, plus a near-future surface that is already being shipped.

Duane Forrester’s The Machine Layer is the canonical guide for the visibility-and-trust side of the journey. Read it. Machine-First Architecture is what you build under that, wrapping the same content discipline inside the full architectural span, with Identity at one end and Interaction at the other.

The piece on the technical SEO audit I linked in the opening is the audit you run once the architecture is in place. The accessibility tree work I covered earlier is the rendering surface where most agentic browsers actually read your website, which is where the Structure Pillar’s information hierarchy ultimately gets evaluated.

Mobile-first took years to fully play out, but the actual transition (the point where websites that ignored it started losing) happened in months. Once Google began penalizing non-mobile-friendly websites in 2015, the window for ignoring it closed.

Machine-first is following the same curve, compressed.

More Resources:

Featured Image: Olga S L/Shutterstock

Ecommerce MGMT 0 Comments
May 25 2026
Pichai Says Google Is ‘A Bit Behind’ On Agentic Coding via @sejournal, @MattGSouthern

Google CEO Sundar Pichai acknowledged the company is “a bit behind” the frontier on agentic coding.

Pichai called coding “very foundational” to Google’s AI work. He made the comments on the New York Times Hard Fork podcast. The interview came days after Google’s I/O developer conference.

Where Google Sees The Gap

When asked about Google’s position in the AI race, Pichai highlighted areas of strength and those where Google trails.

Google’s models are “very capable” on text, multimodality, voice, audio, and reasoning, he said. But in agentic coding, tool use, instruction following, and long-horizon tasks, Google is “a bit behind at this moment.”

On what that looks like for developers, Pichai drew a clearer line. Google has been strong at creating single-shot web front ends. The gap is in longer-running tasks, where developers work on complex codebases.

Pichai said:

“There is a gap to the frontier where others are, but we are working, you know, we are well aware of it.”

Why Pichai Says Google Lacked Coding Data

Pichai pointed to a developer product gap. Google didn’t have the same external coding product surface generating developer data flows, he said.

He cited Anthropic’s relationship with Cursor as an example. Google “maybe quite didn’t have the surface” that competitors had, he added.

That’s now changing. At I/O, Google announced Antigravity 2.0 as a standalone desktop application for agent-based coding workflows. Internal usage at Google has been growing fast, according to Pichai.

He added:

“We are doubling every week and people are really putting the models to work. That is helping us hill climb quite a bit.”

At the I/O keynote, Pichai had shared internal token usage numbers. He called the growth unlike anything he’d seen inside the company.

What Pichai Said About Gemini 3.5 Flash

The interview came a day after Google launched Gemini 3.5 Flash and made it the default model for AI Mode globally. Pichai acknowledged early complaints about pricing, model quality, and usage limits.

Google had tightened usage limits at launch to avoid outages, he explained, calling the restrictions “rightfully a source of frustration.” The company would make progress on limits “very soon.”

On model quality, he acknowledged that the new model could have regressions in some areas. Some issues are “easy to address” through post-training, and Google would fix them quickly, he added.

SEJ covered the Gemini 3.5 Flash launch and other I/O announcements earlier this week.

Why This Matters

Pichai’s comments go further than Google’s I/O keynote messaging on where the company trails. At the event, the focus on Gemini 3.5 Flash and Antigravity was more confident. This interview offered a more candid read on the competitive picture.

Pichai described the gap as a feedback loop problem. Coding products that developers use daily generates interaction data that improves the next model. By his own account, Google is now building that loop through Antigravity after lacking a similar developer-facing surface.

Looking Ahead

Pichai said Google is making progress on coding and called the space “very dynamic.” Google says Gemini 3.5 Pro is being used internally and is expected to roll out next month. It hasn’t said whether the model will narrow the coding gap Pichai described.

Featured Image: YouTube / Hard Fork podcast

Ecommerce MGMT 0 Comments
May 20 2026
Mueller Explains Why Google Uses Markdown On Dev Docs via @sejournal, @MattGSouthern

Google’s John Mueller says markdown pages serve a specific purpose for developer documentation sites but won’t help most websites, even as search becomes more agentic.

Mueller laid out his reasoning in a Bluesky thread. He was responding to a question from Lily Ray about why Google publishes LLMs.txt files and markdown pages, even though they aren’t needed for search performance.

His response focused mainly on markdown versions of developer documentation, not llms.txt as a standalone file.

Mueller wrote:

“The short answer is that it’s not done for search. There’s more to websites than just SEO :-).”

Mueller’s Discovery Vs. Functionality Framework

His reasoning focuses on two different website goals.

He called the first “discovery,” or being found via a search engine, and the second “functionality,” which helps users complete tasks on the page.

Mueller acknowledged the term wasn’t precise. “There’s probably a more accurate term for this,” he wrote in the thread.

He compared the distinction to calls to action on traditional pages, stating:

“You don’t ‘do them’ for SEO (to be found), but if you’re responsible for the website overall, ensuring a high ‘discovery rate’ (SEO) together with a high conversion rate is useful to justify your work.”

Why Developer Docs Are Different

On developers.google.com, he noted, markdown versions make sense.

Mueller said;

“AI coding has gotten very popular, and these coding systems can be (I think) efficient and accurate with the code they produce if they can easily read / parse reference material, such as developer documentation.”

He added that markdown can help AI systems “understand the context of the documentation they’re looking at, as well as a simplified version of the reference page.”

Mueller called this a workaround rather than a long-term need, adding:

“OF COURSE they can read HTML just fine, so this is imo more of a temporary crutch, perhaps to save some tokens.”

Non-Developer Sites Should Skip It

For everyone else, Mueller was direct, stating:

“For non-developer sites, I don’t think this makes much sense, even with more agentic traffic in the future. Making a markdown version of a shoe’s specs is not going to get you more sales (competitors appreciate it tho).”

He went further in a follow-up post, pushing back on the idea that sites should prepare for a future where agents drive more traffic.

Mueller added:

“And (I know, nobody reads this far), if you think this is important to prepare for when agents are everywhere: your site (all sites) have much more important things to do for SEO than to prepare for a potential future situation that may or may not come. Prioritize needs before dreams.”

Why This Matters

Mueller’s comments show a more detailed position than his earlier statements on the topic.

In February, Mueller called the idea of serving markdown pages to bots “a stupid idea.” His Bluesky comments carve out an exception for developer documentation while holding the line for every other type of site.

The thread also arrived on the same day we reported that Google’s guidance on llms.txt now depends on which product you ask. Google’s generative AI optimization guide says to skip llms.txt, while Lighthouse 13.3 added an experimental audit that checks for the file as part of agentic browsing readiness.

Looking Ahead

Mueller’s distinction between discovery and on-page functionality can help you evaluate whether agentic optimization is worth their time. The test is whether building for agents right now produces measurable results for a specific site.

The “prioritize needs before dreams” line captures a broader tension in the industry right now. Vendors have been promoting llms.txt and markdown optimization as emerging practices, but neither Google’s search documentation nor independent data support investing in these for non-developer sites.

Featured Image: kirill_makarov/Shutterstock

Ecommerce MGMT 0 Comments
May 20 2026
Google’s llms.txt Guidance Depends On Which Product You Ask via @sejournal, @MattGSouthern

Google’s Search and Chrome documentation now point in different directions on llms.txt, depending on whether the goal is Search visibility or agentic browser readiness.

Google Search recently published a new optimization guide that lists llms.txt among the tactics you don’t need for generative AI features. The guide groups it with content chunking, AI-specific rewriting, and special schema.

Days earlier, Google’s Lighthouse tool shipped version 13.3, which added a new Agentic Browsing category. The update includes an llms.txt audit that checks whether a site provides the file and flags server errors when retrieving it.

The Lighthouse documentation describes llms.txt as a way to provide “a machine-readable summary of a website’s content, specifically designed for LLMs and AI agents.” It adds that without the file, “agents may spend more time crawling the site to understand its high-level structure and primary content.”

What Google Search Has Said

Google’s Search team has maintained for over a year that llms.txt is not a Google initiative or something Google plans to adopt.

John Mueller compared llms.txt to the keywords meta tag, noting no AI services used it and bots didn’t request the file. He called building separate Markdown pages for bots “a stupid idea.”

At Search Central Live Deep Dive Asia Pacific, Gary Illyes and Amir Taboul confirmed Google was not pursuing llms.txt.

Google’s optimization guide explicitly states llms.txt should be skipped, providing the most recent direct statement from the Search team.

What Chrome’s Lighthouse Now Does

Lighthouse 13.3 ships with the Agentic Browsing category by default, checking WebMCP integration, agent accessibility, layout stability, and llms.txt.

The llms.txt audit only marks sites as “Not Applicable” if they return a 404; errors flag the audit. The Lighthouse docs describe llms.txt as an “emerging convention” at llmstxt.org, advising site owners to create and place it in their root directory.

This category is separate from SEO audits and indicates that llms.txt helps browser-based agents understand site structure, not improve search rankings or AI citations.

Google Has Been Here Before

Google’s internal teams have sent mixed signals on llms.txt before.

In December, Lidia Infante spotted an llms.txt file on Google’s Search Central developer documentation. Mueller responded on Bluesky with “hmmn :-/” and didn’t clarify further.

Dave Smart noted that the file appeared on multiple Google developer properties, including developer.chrome.com and web.dev. The pattern suggested an internal CMS platform update that automatically deploys llms.txt files, not a Search team decision.

The Search Central file was removed within hours, but files on other Google properties remained.

Why This Matters

Google’s answer on llms.txt varies by use case.

For Google Search, llms.txt isn’t needed for AI Overviews, AI Mode, or other generative AI Search features.

For browser-based agents, Lighthouse considers llms.txt optional in an experimental machine interaction category.

Guidance is split between different Google developer sites, which can lead to conflicting instructions when comparing Lighthouse or its llms.txt documentation with Google’s Search docs.

Looking Ahead

Google hasn’t commented on the documentation gap between the two product teams.

For many sites, creating a basic llms.txt file is simple, but maintaining it is questionable, given that Google Search states it’s unnecessary for AI Search visibility.

Featured Image: Stock-Asso/Shutterstock

Ecommerce MGMT 0 Comments
May 5 2026
Google Testing Web Bot Auth To Verify AI Agent Requests via @sejournal, @MattGSouthern

Google published documentation explaining its testing of Web Bot Auth, an experimental IETF protocol that can help websites cryptographically verify some automated requests from bots and AI agents.

The protocol adds another verification layer by letting agents sign HTTP requests with cryptographic keys. Websites can then verify those signatures against published public keys to confirm the request came from who it claims to be.

What’s New

Web Bot Auth uses HTTP Message Signatures (RFC 9421) to let automated clients sign outgoing requests. A bot holds a private key, publishes its public key at a known URL, and signs each request. The receiving website checks the signature against the public key to confirm identity.

Google says a subset of signed Google-Agent requests are authenticated as https://agent.bot.goog. Signed requests include a Signature-Agent HTTP header set to g="https://agent.bot.goog", and the corresponding signature can be verified using public keys published at that domain’s .well-known directory.

According to Google’s documentation, bot-detection services, CDNs, and WAFs already support the protocol. The IETF draft is authored by Thibault Meunier of Cloudflare and Sandor Major of Google. Cloudflare publishes a reference implementation on GitHub.

The IETF Web Bot Auth Working Group was chartered in early 2026 with milestones for standards-track specifications and a best current practice document.

What Google Is Not Doing Yet

Not all Google user agents are participating. The documentation says Google is testing with “some AI agents hosted on Google infrastructure” but does not name which ones beyond the Google-Agent user-triggered fetcher.

Even for participating agents, not every request is signed. The documentation recommends that sites continue relying on IP addresses, reverse DNS, and user-agent strings as the primary verification method while signed traffic rolls out gradually.

The Internet-Draft could change as the working group develops the standard.

Why This Matters

Bot impersonation has been a persistent problem. Scrapers and bad actors can spoof user-agent strings to disguise their traffic as Googlebot or other legitimate crawlers, making it harder for site owners to tell real bot traffic from fake.

We covered this issue when Google’s Martin Splitt warned that “not everyone who claims to be Googlebot actually is Googlebot.” The available verification methods at the time were reverse DNS lookups and IP range checks. Web Bot Auth would add a layer that can’t be forged without the agent’s private key.

For sites already using a CDN or WAF that supports the protocol, verification may happen automatically. For everyone else, the experimental status means there is no urgency to act. The documentation recommends treating existing verification as the default and Web Bot Auth as supplementary.

Looking Ahead

Web Bot Auth is still moving through the standards process, and Google’s implementation remains experimental.

For now, the practical change is visibility. Websites may start seeing signed requests from some Google-Agent traffic, while existing verification methods remain the default.

The next question is whether more AI agents adopt signed requests, and whether hosting providers make verification automatic for websites that don’t want to manage keys.

Ecommerce MGMT 0 Comments
May 3 2026
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

Ecommerce MGMT 0 Comments
May 1 2026
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

Ecommerce MGMT 0 Comments
Apr 26 2026
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

Ecommerce MGMT 0 Comments
Feb 13 2026
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.

Ecommerce MGMT 0 Comments