May 27 2026
Core Web Vitals: WordPress And Astro Versus Everyone Else via @sejournal, @martinibuster

HTTP Archive’s latest Core Web Vitals Technology Report ranks seven content management platforms and offers the surprising insight that page weight and PageSpeed Insights Lighthouse scores do not always predict Core Web Vitals performance.

Why Core Web Vitals Matter

Core Web Vitals (CWV) are metrics created by Google to show:

  • How quickly a web page loads
  • How stable it remains during loading
  • And how responsive users may perceive the page.

While Core Web Vitals is a minor ranking factor, it is important because pages with high CWV scores perform faster and more smoothly for users and can benefit site owners with higher conversions and better ad performance. Sites with lower scores tend to present users with friction that can frustrate them, which in turn can increase abandonment rates and negatively impact conversions.

Does Page Weight Impact Core Web Vitals?

It is commonly understood that page weight affects Core Web Vitals scores. But page weight is not necessarily the dominant factor. So this comparison also examines median page weight to understand how closely it correlates with low or high CWV scores.

What emerges from the comparison suggests the relationship is not quite as straightforward as it seems.

How The Data Is Collected

The Core Web Vitals Technology Report combines public data from the Chrome UX Report (CrUX) and the HTTP Archive project. The data used for this comparison comes from global statistics, which can give a broader view of how websites perform across the widest range of devices and internet connections.

  • CrUX collects anonymized real-world field performance data from Chrome users who opt into sharing usage statistics.
  • HTTP Archive collects lab-based performance and technology data by crawling and testing websites across the web.
  • The HTTP Archive median page weight dataset measures the typical transfer size of pages over time.

Comparing the two datasets (CrUX and HTTP Archive) makes it possible to examine whether page weight correlates with measured and real-world Core Web Vitals performance.

Duda Ranked Highest For Core Web Vitals

Duda ranked first in Core Web Vitals performance with approximately 85% of sites receiving a good CWV score. It also maintained one of the lightest median page weights in the comparison at roughly 1.78 MB.

The relationship between lighter pages and stronger CWV performance is immediately apparent. Duda paired relatively lightweight pages with the strongest CWV performance in the dataset.

#2 Ranked CWV Platform: Wix

Wix ranked second with roughly 80% of sites receiving a good CWV score.

Its median page weight measured approximately 2.55 MB, noticeably heavier than Duda but still lighter than several lower-performing platforms.

The data continues reinforcing the broader trend. Platforms carrying lower page weight generally clustered near the top of the CWV rankings.

#3 Ranked CWV Platform: Shopify

Shopify is ranked third for Core Web Vitals performance with roughly 79% of sites receiving a good CWV score. That’s a surprisingly strong ranking because shopping site performance tends to get dragged down by third-party scripts, customer tracking, and shopping-related features. Shopify sites also had the worst page weight scores and Lighthouse audit scores.

Page Weight Scores April 2026 (Lower Is Better)

  1. Astro: 1.65 MB
  2. Duda: 1.87 MB
  3. Drupal: 2.39 MB
  4. Joomla: 2.65 MB
  5. Wix: 2.67 MB
  6. WordPress: 2.76 MB
  7. Shopify: 3.77 MB

Lighthouse Audit Scores April 2026 (Higher Is Better)

  1. Astro: 68
  2. Wix: 62
  3. Duda: 54
  4. Drupal: 48
  5. Shopify: 47
  6. WordPress: 44
  7. Joomla: 43

Shopify sites had all these factors working against them and yet they still outperformed nearly all the other platforms in this comparison. What is going on?

The first takeaway is that reducing Page Weight is only one factor out of several for improving Core Web Vitals performance.

Another insight is that Lighthouse lab audit scores and real-world Core Web Vitals are not rewarding exactly the same things.

The Lighthouse audit is sensitive to:

  • JavaScript payload
  • Unused JS
  • Render-blocking resources
  • Synthetic throttling conditions
  • Image inefficiencies
  • Network waterfall structure

Why Shopify Sites May Score Highly For CWV

Sites hosted on Shopify may have high real-world Core Web Vitals performance because Shopify maintains stable rendering behavior, uses layouts coded to avoid shifting, delivers interactivity quickly, and aggressively optimizes resource delivery through CDN infrastructure and its hosting environment.

The above factors are the very things that respond well to real-world CrUX measurements:

  • Measures actual user experience
  • Includes caching effects
  • Includes CDN behavior
  • Includes repeat visits
  • Reflects real devices and connection conditions
  • Measures whether the page ultimately feels responsive and stable to users

Shopify’s results show that a site can have high page weight and low Lighthouse audit scores and still deliver a high-quality Core Web Vitals experience to users. Optimizing shopping websites is not easy. Shopify’s performance in this comparison is worth recognizing.

Why Does Astro Have Good Scores?

67% of sites using Astro received a good CWV score, placing it solidly in fourth place. Astro also maintained the lightest median page weight in the dataset. That combination of light page weight and solid Core Web Vitals performance reinforces the intuition that lightweight pages help with CWV scores. But Shopify’s example shows that page weight is not the only path toward better CWV performance.

Astro deserves a closer look, however, because the high CWV scores could be a reflection of the kinds of sites being deployed with it. For example, straightforward blog-style sites don’t need the kind of complex functionalities that drag down Core Web Vitals scores.

Astro performs well out of the box, but so does WordPress. A further review may show that the out-of-the-box Astro advantage may fade as website complexity increases.

Drupal Delivers Reliable CWV Performance

Drupal ranked fifth with roughly 64% of sites receiving a good CWV score.

Its median page weight measured approximately 2.28 MB, placing it near the middle of the comparison in both CWV performance and page weight size.

Drupal’s performance scores from January through April 2026 shows stability with no swings up or down. It began the year at 64% and ended April with the same 64% score. Stability is good, but an upward improvement, even a modest one, is arguably preferred.

What Is Undermining Joomla’s CWV Performance?

Joomla ranked sixth with approximately 58% of Joomla-based sites receiving a good CWV score.

The median page weight of sites using Joomla measured approximately 2.53 MB, which is better than some of the higher CWV ranked websites. This is another anomaly where a platform delivers low page weight but mediocre Core Web Vitals scores.

A review of HTTP Archive’s Lighthouse Audits performance shows that Joomla had the lowest Lighthouse scores of all the CMS platforms in this comparison.

Joomla Scores Lowest On Lighthouse Audits

  1. Astro: 68
  2. Wix: 62
  3. Duda: 54
  4. Drupal: 48
  5. Shopify: 47
  6. WordPress: 44
  7. Joomla: 43

Those low scores may indicate that execution factors, such as render-blocking resources, JavaScript behavior, image handling, and template or extension quality, may be the factors weighing down real-world CWV performance for Joomla-based sites.

WordPress Is Last Again

WordPress is ranked dead last in this comparison with approximately 49% of sites receiving a good CWV score. It ranked second to last in Lighthouse Audits just behind Joomla and was second to last for page weight with a median page weight of approximately 2.63 MB.

The contrast with Duda and Astro is especially sharp when comparing page weight:

  • Websites created with Duda were 1.87 MB
  • Websites created using Astro averaged 1.65 MB. .
  • WordPress sites had a median page weight of approximately 2.63 MB.

The gap between the platforms is large enough that they no longer appear to be operating within the same performance range.

Median Page Weight And CWV Performance

The platforms with the lightest median page weights didn’t directly correlate with top Core Web Vitals performance.

Page Weight

  1. Astro: 1.57 MB
  2. Duda: 1.78 MB
  3. Drupal: 2.28 MB

Core Web Vitals Performance

  • Duda: 85%
  • Wix: 80%
  • Shopify: 79%

Low Page Weight Does Not Guarantee Good CWV Performance

The data appears to support a relatively straightforward conclusion: lighter pages generally produce stronger Core Web Vitals performance. But Shopify shows that optimizing for page weight is not the sole path to better CWV performance. The answer lies in how efficiently platforms handle website complexity.

Shopify’s pages carry far more weight than competing platforms, largely because e-commerce sites require extensive JavaScript, product filtering systems, dynamic inventory functionality, images, personalization features, and interactive storefront elements.

Under a simplistic payload-size model, Shopify should perform considerably worse. But the platform continues producing CWV scores that outperform more lightweight platforms.

That suggests the conversation around performance should be as much about managing web page complexity as it is about minimizing page weight. The example of Shopify sites appears to point to web page complexity as the more important factor to optimize for.

  • A lighter platform may still perform poorly if rendering and execution are handled inefficiently.
  • A heavier platform may still perform well if its architecture aggressively optimizes how that complexity is delivered to users.

That’s the big takeaway from the comparison of different platforms.

Nevertheless, sites that are lightweight generally tended to demonstrate stronger CWV performance. But Shopify forces a more nuanced conclusion because it demonstrates that payload size alone does not determine outcomes.

The competitive advantage increasingly appears to belong to platforms capable of carrying complexity efficiently.

Takeaway

What Shopify’s results really show is that Core Web Vitals performance is not simply a contest to see which platform can ship the smallest pages. The more important question is what happens after real-world complexity enters the picture.

That’s where the individual CWV metrics become useful because they reveal the specific ways websites fail under pressure.

Largest Contentful Paint (LCP) often breaks when platforms load oversized images, delay discovery of the main image, block rendering with CSS and JavaScript, or force browsers to compete against too many high-priority resources at the same time. A site can have relatively small overall payloads and still perform poorly if the browser struggles to identify and render the most important visual content quickly.

Interaction to Next Paint (INP) exposes another weakness. Third-party scripts, tracking tags, hydration overhead, popups, sliders, chat widgets, and excessive JavaScript execution can all block the browser’s main thread and delay responsiveness. This is where website complexity becomes expensive because every additional feature competes for execution time.

Cumulative Layout Shift (CLS) often breaks when layouts are unstable. Images without reserved dimensions, late-loading ads, embedded media, injected interface elements, and dynamic content can all push visible content around while users are attempting to interact with the page.

This is where Shopify’s results become more interesting. Shopping sites naturally carry many of the exact elements that tend to damage LCP, INP, and CLS scores. Shopify also ranked only in the middle of the Lighthouse performance scores, which means its lab-test results were not especially strong compared with the rest of the platforms.

And yet Shopify still maintained one of the strongest real-world CWV performances in the comparison. When talking about CWV many SEOs focus on making sites faster. But if we’re going to take away something from this comparison, it’s that real-world CWV performance may come from how well a website handles the technical failure points and not focusing only on page weight type improvements.

Featured Image by Shutterstock/n_defender

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 26 2026
846,000 Google Searches Reveal How AI Overviews Are Changing User Behavior via @sejournal, @ericvanbuskirk

If a user types your brand name into Google or Chrome, you might reasonably assume they are about to visit your website. Google has always been a place people pass through on the way to somewhere else, but AI Overviews are changing how long that passage takes, and what happens during it.

To assess these changes, I analyzed 846,000 U.S.-based Google Search sessions from anonymized clickstream data for February and March 2026.

We measured what click and ranking data cannot capture: what people read, skim, and scan on the search results page before they make decisions. Where does their cursor travel? How far do they scroll? Do they reverse direction? And how does all of that change when Google’s AI Overview is present?

Cursor tracking is a useful proxy for attention because cursor position often aligns with gaze during active reading and decision tasks, but it is less reliable during passive, distracted, or idle browsing. Cursor positions were sampled at one-second intervals during search sessions, up to 60 samples per session.

What we found is the search result preview carries more weight for brands. Where AI Overviews are shown, users stay longer on Google as they read, revisit, and compare listings carefully.

Image from author, May 2026

1. AI Overviews Keep People On Google Far Longer, Regardless of Why They Searched

We tracked how many users were still actively engaged with the SERP at each three-second interval from the moment their search appeared, from 3 to 21 seconds.

We did this separately for five types of searches: informational, local, navigational, transactional, and video, and compared what happened when an AI Overview was present versus absent.

Image from author, May 2026

The result was striking. Without an AI Overview, searchers behave like five distinct audiences. With one, they behave like one audience.

For brands, the time between a user seeing your listing and deciding what to do with it has expanded considerably. That extended window is a challenge because Google holds attention longer before releasing it. It is also an opportunity because users who click after spending 15 or 20 seconds evaluating the page are likely making a more considered choice.

Has AIO Search Type 3s 6s 9s 12s 15s 18s 21s
No Informational 70.2% 51.5% 40.3% 33.0% 27.7% 24.2% 21.6%
Yes Informational 92.2% 80.2% 70.4% 62.3% 55.7% 50.3% 45.4%
No Local 81.8% 65.6% 54.1% 46.3% 40.2% 35.7% 32.3%
Yes Local 91.9% 79.1% 68.4% 59.3% 52.2% 46.6% 41.9%
No Navigational 52.9% 35.0% 25.9% 20.4% 16.6% 14.1% 12.0%
Yes Navigational 92.5% 81.1% 71.6% 63.1% 56.0% 50.3% 45.8%
No Transactional 75.0% 57.0% 46.0% 38.4% 32.6% 28.2% 24.9%
Yes Transactional 92.9% 81.9% 72.7% 65.0% 58.2% 52.1% 47.4%
No Video 74.4% 56.4% 45.2% 37.6% 31.9% 27.2% 23.4%
Yes Video 93.1% 82.2% 72.8% 65.5% 59.0% 53.3% 48.5%

Without an AI Overview, behavior varies sharply by search type. Navigational searchers were gone the fastest, with only 12% still active at 21 seconds. Local searchers were the most engaged, with 32% still active at the same point, most likely because local results pages are rich in maps, business listings, and reviews that naturally spread attention across multiple elements.

With an AI Overview present, those differences nearly disappear. At three seconds, all five intent types are clustered between 91.9% and 93.1% still active. At 21 seconds, they remain tightly grouped between 41.9% and 48.5%.

This finding used our balanced dataset, meaning each search type was represented in a way that supports fair comparison across intent groups and AIO conditions. It is the only finding in this research that examined engagement purely in terms of time: are people still there, or have they left?

Why this matters for your website or brand: AI Overviews make the gap between seeing your listing and clicking it longer and more deliberate.

2. The Navigational Searcher Transformation

An engagement-equalizer effect hit hardest for navigational searches. Queries where someone types a brand name or website address directly into Google. These users have historically been the most reliable source of organic traffic; they already know where they want to go. This was especially true when people search in a browser bar connected to Google Search and were in a rush.

Without an AI Overview, only 12% of navigational users were still active on the results page at 21 seconds. With one, that figure rises to 46%. Users who would have been on your site within seconds are now spending far longer on Google before acting.

Cursor behavior tells the same story from a different angle. We measured how widely users’ cursors moved across the visible search page, combining both side-to-side and up-and-down movement into a single cursor-spread score. Without an AI Overview, navigational searchers showed the most concentrated cursor activity of any intent type: their cursor spread measured 8%, reflecting a tight, purposeful scan.

When an AI Overview is present, that figure jumps to 27.5%, indicating that even highly directed users engage with a much wider area of the page before reaching their destination.

Why this matters for your website or brand: Navigational searches have historically been close to guaranteed organic visits. A user who types your brand name directly into Google is already past the awareness and consideration stages. This data suggests that when an AI Overview appears on those searches, even the most directed users are being pulled into a broader exploration of the page before clicking through. (Balanced dataset)

3. Less Movement, Wider Coverage

We measured how searchers’ cursors moved within the visible search results page. When an AI Overview is present, users move and pause their cursor differently.

Users with an AI Overview kept their cursor still more often, about 44% of the time, compared to 29% when no AI Overview was present. At first glance, that could sound like disengagement. But those same users covered more of the screen with cursor movement, sweeping across 83% of the viewport compared to 66% without an AI Overview.

Image from author, May 2026

More pausing plus more ground covered suggests a reading-and-evaluating mode rather than a scanning-and-clicking mode. Users are not simply skimming the top and clicking. They appear to pause, move to another part of the page, and repeat.

This analysis examined cursor behavior across all search types, using a dataset that reflects how real searches break down in the wild. Informational searches make up the large majority of real-world queries, and that is reflected here.

Why this matters for your website or brand: The traditional mental model of a Google search result is that users scan the top few results, click the most relevant one, and move on. This finding suggests the model is changing.

That does not mean lower-ranked results are getting more clicks. It means the page is being traversed more thoroughly before a decision is made. Your title tag and meta description carry more weight because users appear to pause over search snippets rather than reflexively clicking the first result.

If your listing appears on a page with an AI Overview, you are competing in a slower, more considered decision environment. That rewards clarity and relevance in how your result is written, not simply rank position.

4. When AI Overviews Are Present, People Scroll Back Up Far More Often

Most people think of scrolling as a one-way journey: down the page toward the results. What we measured tells a different story. Users regularly scroll back up during a search session, and when an AI Overview is present, they do it substantially more. Your listing may get multiple looks, not one.

We tracked two things: whether a user reversed direction at any point during the session, and what proportion of total scrolling was spent going up the page rather than down. Both measures shift with AIO, but the second measure is the larger story.

Image from author, May 2026

The share of users who reverse direction at all increases modestly with AIO, from 51% to 59%. Among people who do reverse, the median user with an AI Overview spends nearly half, 47.5%, of total scrolling going back up the page. Without an AI Overview, that figure is 27%.

We tested informational and navigational searches for this. Both tell a consistent story. Navigational searchers show the largest shift, with back-scrolling percentage jumping from 23% to 44% when AIO is present. This reinforces a pattern seen in other findings: Users who normally move with purpose and speed are pulled into a more deliberate, back-and-forth mode of engagement by the presence of the AIO. (Representative dataset)

Why this matters for your website or brand: Back-scrolling is a signal of active comparison and reconsideration. When a user scrolls down, reads something, then returns upward before continuing, they are weighing options, not just taking the first thing they see.

A vague or generic title and description may pass a quick scan but fall short when a user returns to compare it directly with a competitor’s listing. Clarity and specificity in your result preview become a competitive advantage in this environment.

Summary Of Findings

  • AI Overviews slow the search experience and expand the decision-making window on the page itself. Users who encounter an AI Overview stay on Google longer, read more of the page, scroll back up more often, and show patterns consistent with active comparison rather than quick selection.
  • For dwell behavior, AI Overview presence is a stronger predictor of user behavior than the type of search the person was conducting. This study looks at the SERP as a place where users pause, reverse direction, revisit content, and compare, and not simply a click surface.
  • Without an AI Overview, dwell behavior varies by intent. With an AI Overview, those differences flatten into a narrow band, with roughly 42% to 49% of users still active on the page at 21 seconds across all five intent types.
  • Among users who reverse scrolling direction, nearly half of the total scrolling on AIO pages is spent going back up the page, revisiting content they have already passed. These are not users simply rushing to a result. They are working through the page, weighing options, and reconsidering.

For brands, the practical implication is straightforward – the search result preview now carries more weight. Users appear to read, revisit, and compare listings more carefully before abandoning the SERP. The brands best positioned in this environment are those whose search presence is built for scrutiny, not just discovery.

Methodology

ClickStream Solutions analyzed, interpreted, and produced the findings from anonymized clickstream data provided by Surfer SEO. The data contained approximately 846,000 Google Search sessions from February and March 2026.

Because Surfer’s audience is composed of marketing-interested people, the findings may skew toward more search-savvy users. Their sessions included both work and non-work-related Google Search use. Only 1.1% of sessions involved marketing-related queries, with the remaining 98.9% spread across other categories. All users were in the USA.

Data was anonymized prior to analysis with no personally identifiable information retained. Users were informed that mouse movements might be captured.

The study used three analysis datasets: a balanced dataset of 74,848 sessions for fair comparisons across search types and AIO conditions (used for Findings 1 and 2); a representative dataset of 99,994 sessions reflecting the natural mix of real searches (used for Findings 3 and 4); and a filtered representative dataset of 99,994 sessions that excluded sessions with fewer than 3 seconds or more than 25 seconds on the SERP.

More Resources:

Featured Image: Viktoriia_M/Shutterstock

Ecommerce MGMT 0 Comments
May 26 2026
How GenAI Platforms Produce Answers

Google’s recent AI optimization guidelines apply only to its search portal with AI Overviews and AI Mode, and not necessarily to Gemini or other generative AI platforms such as ChatGPT and Claude.

Visibility on those platforms is crucial, yet none provide guidance or suggest tactics. A useful first step is to understand how the platforms generate answers to prompts.

I’ll explain in this post.

1. Training layer

Upon receiving a prompt, genAI platforms first check whether their training data includes enough info on the topic to answer. In many cases, training data is sufficient, and the process stops there.

Training data doesn’t store URLs, nor does it rank sources, unlike traditional search engines. The data comes from known brands with clear value propositions that answer or solve a need.

2. Retrieval eligibility

Next, if the training data is insufficient, the platform will query search engines, as humans do.

At this point, visibility relies on search rankings. No genAI platform discloses where it searches, but studies reveal it is mostly Google. The platforms presumably rely on highly ranked URLs, although I’ve seen no definitive clarity on that selection process.

3. Extraction

At this point, a genAI platform has performed searches and found URLs for answers. Then it may crawl those pages to extract information.

This is where clear headings, short factual sentences, and Q&As lead to inclusion in answers, but only if the URL was found and crawled.

4. Citation-slot assignment

But inclusion does not always mean a citation. How do the platforms choose which sources to cite? In many cases, it’s not the source that supplied the answer.

Some independent studies suggest that citations originate in the retrieval stage (step 2 above) but were neither crawled nor used to create an answer. Others believe citations are part of official partnerships with publishers.

Some URLs are hallucinations and never existed.

Hence throughout the entire answer-generation process, SEO impacts only steps 2 and 3.

Step Purpose Impact Optimization
Training layer Determine if answer already exists Likely supplies the answer Brand awareness, trust, clear positioning
Retrieval eligibility Search Google for the answer Possibly included in the answer if selected SEO
Extraction Assess potential answers on the page Could provide an answer if crawled SEO on page: Content clarity, structure, semantic relevance
Citation slots Select pages to cite URL can be cited but not included in the answer Unknown

Ecommerce MGMT 0 Comments
May 25 2026
Digital PR Hasn’t Changed – AI Search Just Made The Fundamentals More Important via @sejournal, @gregjarboe

Last week, I read Giulia Panozzo’s article about rethinking audience targeting in a signal-loss era. I also read Harry Clarkson-Bennett’s article about creating non-commodity content. And then I read Matt G. Southern’s article about Google’s new AI search guide officially calls AEO and GEO “still SEO.”

Reading them together, I kept hearing the same message: the fundamental things apply.

And that sent me back to something I wrote on August 11, 2022 – two and a half months before OpenAI released ChatGPT – “7 Steps To Building A High-Impact Digital PR Campaign,”

What I Borrowed From Aristotle

In my August 2022 article, I disclosed that the framework wasn’t mine. The honor goes to Aristotle, who articulated his “elements of circumstance” in the Nicomachean Ethics in the 4th century BCE. Who, what, when, where, why, in what way, and by what means. All I did was apply them to SEO PR in the 21st century. The question worth asking now, 42 months and one AI revolution later, is whether the seven steps still hold.

They do. But what each step requires has changed.

Who Are Your Target Audiences?

In August 2022, this step was primarily about demographics and keyword personas. But signal loss is not a new problem – it’s a recurring one. In 2013, Google’s move to encrypted search made “keyword not provided” a major problem, stripping away the keyword-level analytics data that practitioners had relied on to understand who was actually finding their content and why. We adapted. We found other signals.

Today, the challenge has another layer. The data holes in Google Analytics 4 are real – I’ve written about them at length. The R.E.M. Framework Panozzo describes is addressing what to do when the data you relied on to define your audience has become unreliable or incomplete. Her answer, and mine, is the same: Get closer to actual people rather than proxy data. Signal loss is an inconvenience for lazy audience definition. It is an opportunity for practitioners disciplined enough to gather first-party signals through direct observation.

What Is Their News Search Intent?

Google’s new AI search guide, published this week, makes something explicit that has been implicit for years. AEO and GEO are not separate disciplines from SEO. They are SEO, applied to generative AI features. The underlying question has always been the same: what is someone actually trying to understand or accomplish when they search?

What has changed is the format of the answer they now expect. In AI Overviews and AI Mode, the answer comes first. The citation comes second, if at all. For digital PR, this means the question is no longer just “can we rank for this?” but “can we earn a citation in the answer Google generates?”

The intent question remains. The answer format has changed around it.

When Do They Conduct News Searches?

This step is relatively stable, though the tools for measuring temporal search patterns have improved considerably. Clarkson-Bennett’s piece makes the practical point well: Google Trends data for terms like “family holidays” shows spikes every January with near-perfect consistency across five years. Seasonal patterns in news search intent are more durable than most practitioners assume, and AI Overviews have not disrupted the underlying rhythms, only the interface through which people receive answers.

Where Do They Conduct News Searches?

This is where the 42 months have brought the most visible change. In August 2022, “where” meant Google Search, Google News, YouTube, and social platforms. Today, the answer includes ChatGPT, Perplexity, Claude, Gemini, and AI Mode within Google itself.

The Similarweb traffic data for April 2026 tells the story plainly. ChatGPT logs 5.5 billion monthly visits globally, but Google still leads with 84.8 billion monthly visits. So, the “where” of information-seeking has genuinely fragmented in ways that matter for distribution strategy.

A news story that earns visibility only in traditional Google Search is now reaching a smaller fraction of the total information-seeking audience than it was in 2022. The PR question of “where will this land?” requires a broader answer.

Why Does Your News Matter To Your Target Audiences?

This is the step that Amit Singhal’s 23 Panda questions were really about, back in 2011. “Does the article provide original content or information, original reporting, original research, or original analysis?” That question appeared in Google’s quality guidance 15 years ago. It appears, in updated form, in Google’s new AI search guide this week.

Clarkson-Bennett’s piece makes the same point through the concept of information gain – a patent Google has cited frequently, worldwide, and with recent updates, which estimates effort and rewards documents that add something not already present in the index. The commodity content problem is not new. The Panda update was Google’s first systematic attempt to solve it. The AI era is the latest, and most technically sophisticated, iteration of the same enforcement mechanism.

Why does your news matter? Because it is original, specific, and cannot be replicated by pattern recognition across what already exists.

In What Way Can You Change Hearts, Minds, And Actions?

The Panda question that applies here: “Does the article have the kind of quality you’d expect to see referenced by a magazine, encyclopedia, or book?” That standard hasn’t lowered in the AI era. If anything, it has become the threshold for citation rather than just for ranking.

AI-generated summaries cite sources that carry authority, specificity, and genuine expertise. The PR content most likely to earn that citation is the content that would have passed Singhal’s 23 questions in 2011 and still passes them today. Original research. Primary sources. Specific claims grounded in verifiable data.

The means of changing minds have not fundamentally changed. What has changed is that the audience may now receive your argument through an AI intermediary rather than directly. The quality standard required to survive that intermediation is higher, not lower.

By What Means Can You Measure Your Results?

This is where the 42 months have created the most genuine new work. In August 2022, measurement meant organic traffic, impressions, and backlinks. Today, it requires tracking citation frequency in AI-generated answers, monitoring brand mentions in AI Overviews, and separating AI assistant referral traffic from traditional organic. GA4 added that capability last week, with a new default channel group for recognized chatbot referrers, including ChatGPT and Gemini.

The measurement question Aristotle didn’t have to answer was: How do you know if you’re winning when the audience never clicks through? Citation share of voice in AI answers is becoming the new ranking position. It is measurable. The tools are early and imperfect. But the principle is identical to what it was when SEO measurement began: Identify the signal that predicts whether the right people are finding your content, and track it consistently.

What Aristotle Got Right

Google’s new documentation says AEO and GEO are still SEO. What it means is that the questions beneath the terminology have always been the same: who are you trying to reach, what do they need to understand, and how do you demonstrate to the system surfacing your content that you’ve genuinely answered that need?

Aristotle’s seven elements of circumstance survived 23 centuries before I applied them to digital PR in 2022. They will survive AI Mode, AI Overviews, and whatever Google ships next.

The fundamental things apply.

More Resources:

Featured Image: Roman Samborskyi/Shutterstock

Ecommerce MGMT 0 Comments
May 23 2026
Google I/O Didn’t End SEO. The Risk Is Somewhere Else via @sejournal, @MattGSouthern

The loudest reactions after Google I/O 2026 were that Search had been replaced overnight. Google’s messaging went the other way, insisting that AI Search still depends on the web and existing SEO fundamentals.

The reality sits between those two positions, and the risk most people are naming is the wrong one.

TechCrunch claimed “Google Search as you know it is over.” Time warned of potential industry disruptions. One newsletter called the search bar dead, and LinkedIn posts echoed an “SEO is dead” sentiment shortly after the keynote. However, Google’s Liz Reid stated users will still get a range of results, just like today.

These views all miss a key point.

What Google Announced

Google made significant updates at I/O, including a new Search box that accepts images, files, videos, and Chrome tabs, alongside text. AI suggestions now anticipate user intent, and the box expands with longer prompts.

Gemini 3.5 Flash became the default AI model globally, with AI Mode surpassing one billion monthly users and queries doubling quarterly. Google also launched information agents that monitor the web for users, such as alerting when apartment listings or product updates match their interests.

These agents will initially be available to Google AI Pro and Ultra subscribers this summer, along with generative UI features, mini apps, and dashboards, primarily in the U.S..

Where The Panic Overreached

TechCrunch’s lede declared “The era of the ‘ten blue links’ is officially over.” That line reflected the new UI emphasis on AI answers and agents, but Google didn’t announce the end of web results. Google confirmed that traditional results remain accessible, including through the Web tab. Blue links aren’t gone. They’re being pushed further from the center of the default experience.

Google responded the next day directly. The official @NewsFromGoogle account posted on X:

“AI Mode is not the default experience in Search. Our new search box helps you describe exactly what you’re looking for, but using it does not mean that you will only get AI features — you’ll continue to get a range of results on Search.”

That statement is more specific than anything in Reid’s blog post. It draws a line: the new Search box does not funnel every query into AI Mode.

The claim that “Google is replacing human content with AI’ is misleading. Google didn’t say it no longer needs human-created content. Its optimization guide states that generative AI features depend on ranking systems and the Search index, emphasizing clickable links to supporting pages. The guide highlights non-commodity, self-created content as key for eligibility.

The cycle of “SEO is dead” repeats after every Google announcement. Jess Joyce, an SEO consultant, said on LinkedIn after I/O: “Tomorrow your feed will be full of search is dead takes. It isn’t.”

Joyce’s full post went on to list three specific changes from I/O worth watching. She wasn’t dismissing the announcements. She rejected the idea that the keynote nullified indexing and citation-worthiness overnight.

Where Google’s Messaging Is Too Tidy

The calmer reading shouldn’t defend Google’s position. Four days before I/O, Google released an optimization guide for generative AI in Search, treating AEO and GEO as SEO, and listed five tactics to skip, including llms.txt and content chunking.

Later, the I/O keynote showcased new features such as file and tab acceptance, an interactive UI, background agents, and mini-apps, all signs of real updates. Andrew Holland, Director of SEO at JBH argued against Google claims it’s ‘just SEO,’ but this is a category error; its guidance is system-level correct but underestimates user interface differences.

Google’s stance on llms.txt has been mixed: the Search team has said it’s unnecessary, yet Lighthouse has included an llms.txt audit. Documentation contradicts itself: Search Central advises skipping it, while Chrome suggests considering it, creating confusion for site owners. Meanwhile, Google updated its spam policy to address manipulation of AI responses, expanding its scope as it integrates more AI into Search, illustrating conflicting messaging.

The Real Risk Is Less Need To Click

The main concern arising from I/O is whether people still need to leave Google to access content.

Glenn Gabe, SEO consultant at G-Squared Interactive, wrote on LinkedIn:

“For publishers, information agents can hit ad revenue big-time as less people will be visiting websites.”

Independent analyst Matthew Scott Goldstein posted:

“Not one mention of the publishers and creators whose work feeds every product they announced.”

Information agents synthesize and notify without site visits: they monitor the web, package updates, and deliver them inside Google. The publisher’s content is consumed, but they may not receive a visit.

Google’s AI Mode data show that the average query is three times longer than in traditional search, with follow-up queries up 40% month over month. Planning queries grew 80% faster, indicating users delegate more research to Google.

A field experiment showed that AI Overviews reduced organic clicks on triggered queries by 38%, with no change in user experience ratings. Users got what they needed without extra clicks.

That pattern has lasted over a year. As noted in a Q1 recap, Google’s Robby Stein said that if people don’t engage with an AI Overview, Google might remove it for that query. The most vulnerable pages are simple answer pages like store hours or return policies, which AI can often satisfy without a click.

Information agents go beyond answering single queries; they monitor ongoing needs and provide synthesized updates over time, potentially replacing multiple search sessions with clicks.

The post-I/O panic should have named the risk: fewer users needing links, not links disappearing.

Why This Matters

Simple-answer content is now the most exposed category. AI Overviews and AI Mode can answer queries without redirecting users to your site. This has been true for a year, and I/O announcements accelerate it.

Original analysis, primary data, and expertise that AI can’t synthesize stay separate. Google’s guide highlights this, emphasizing non-commodity content as the only type an AI must cite, not just summarize.

The gap between the two categories widens. Content that repeats existing pages is increasingly served by AI without a click. Content offering unique information still drives visits because the system must show its source.

Google lacks specific Search Console filters to differentiate AI Mode or AI Overview from organic reports. While you can see overall impressions and clicks, isolating AI-driven traffic is impossible, making it hard to gauge how I/O changes impact your site.

Information agents create a new measurement problem: if they monitor your content and provide a synthesis, it may not show up in analytics, even if the content was consumed. The visit didn’t happen.

People opposing ‘SEO is dead’ are correct about fundamentals. Those warning about traffic economics are right about outcomes. The I/O keynote explained why both can be true simultaneously.

Looking Ahead

Information agents launch this summer for premium subscribers, likely expanding access over time. As agent-mediated search grows beyond paid tiers, the click demand issue becomes more significant.

Google hasn’t explained how it will report agent-driven content in Search Console or Analytics. Until then, websites lack complete data on this major change announced this year.

Read more resources:

Featured Image: Roman Samborskyi/Shuttertstock

Ecommerce MGMT 0 Comments
May 22 2026
When Marketing Leaders Can’t Explain Search Performance via @sejournal, @coreydmorris

Search marketing produces an enormous amount of performance data, but many marketing leaders still struggle to explain what those results mean for the business.

SEO and paid search reports often focus on visibility, clicks, and conversion metrics. And, in many cases, data sources for that information don’t match up, as I explored in my previous column.

While valuable, these metrics don’t always translate clearly into business impact and leave chief marketing officers and marketing leaders with reports they can present, but not always confidently explain. And, in some cases, get caught looking defensive and reactionary versus confident and proactive in presenting performance data and having the pulse of what is happening.

I learned this the hard way early in my career as an SEO. A few months into SEO work with an attorney, I had rankings, traffic, and tracked conversions that all looked great. My stomach dropped when I was told, “that’s great Corey, but I didn’t get a single new case from any of this.” It wasn’t comfortable for me back then to go beyond the marketing key performance indicators. As I grew in my career, though, I never forgot about that day.

Today’s attribution world is a mess, and it is more complex when we add in AI visibility, sources, and even Google’s own SERP changes with AI integration to our SEO and SEM data.

This article explores the gap that exists between search marketing performance metrics and executive-level business outcomes, and offers guidance for how marketing leaders can translate search results into meaningful business narratives.

1. Start With The Business Outcome, Not The Metric

The deepest business metric (not marketing) that you have access to is where I recommend starting. There’s not a universal truth on what the ultimate business metric is due to the complexity of different organizations and how much access there is to data, so this is possibly wildly different for everyone.

The goal is to try to remove a CEO vs. CMO disconnect. Or, one between marketing leadership and other leadership functions in a business. It is clear that when marketing leadership is engaged at a business leadership level (not just marketing channels), companies grow faster.

Whether it is actual revenue, customer lifetime value, or something further upstream like qualified leads (and however complex that scoring might be), going beyond the basic web conversion data point can be incredibly helpful in marketing leadership.

When you have the ability to map out business outcome metrics working backward to search metrics, you can demonstrate the impact of the work in a way that shows value versus showing activity.

As a marketing leader, this might seem overly personal, but you can often look at what metrics your role’s performance is accountable for and start there to ensure you have a clear view of search’s impact on those KPIs.

Whether you’re new to your marketing leadership role, or just need to level-set with peers or other executives you report to, a structured goal-setting process can be powerful. You can do so by gaining one-on-one perspectives on what metrics matter to each person. However, it can be really powerful to do this in a workshop format. One where the pressure of past results is off. Most importantly, fostering conversation and Q&A where every person in the room answers questions around what metrics matter to them personally, their functional area, and to the company. This process can help everyone recognize how aligned they are or how far off, which helps you to set a baseline for things that might not be in the purview of marketing, but still have a profound impact on performance measurement.

2. Focus On Fewer, More Meaningful Metrics

When we have too many metrics in our performance data, we can dilute the message we’re trying to convey in reporting. I have sat through presentations that include slide after slide of numbers to only see an executive from another function of the business derail the presentation with impatience, wanting to know what the key takeaway is.

“Is this working?”

“What is the ROI?”

Or, “why are we not showing up for [insert keyword]?” when there’s numbers and KPIs overload.

Not every metric needs to be included in performance reporting, and when you can prioritize what leadership peers or higher-ups actually care about, then you can zero in on it.

These can be uncomfortable questions, challenges, or confrontations in reporting meetings. It can be incredibly helpful for CMOs/marketing leaders to partner with CFOs/financial counterparts to create a shared measurement framework to reduce guessing and to define a shorter, more meaningful set of metrics.

If there isn’t already some type of executive scorecard or overall business reporting format that you contribute to, you might find success in taking a first step in proposing the creation of one. Working one-on-one with a finance counterpart is a great start–as noted. Often, there isn’t an owner or accountable party for unifying all of the metrics. There is likely a source of truth, like a customer relationship management or enterprise resource planning, that matches up down the road with financial reports. Getting buy-in and help on a personal level from other leaders can help make subjective sets of data that different people look at come together in common metrics and shared success language.

3. Explain What Changed And Why

I personally don’t like to use the term “reporting” when looking at performance. I’ve written before about the START Planning Process, where the “R” in that process is intentionally for “review” and not “reporting.”

You can argue with me that this is just semantics (and, since I’m an SEO at heart, I’ll accept a healthy debate), but I feel it is important for there to be balance in any level of performance analysis. Reporting, in my mind, is looking at what happened and into the past. Review has some “reporting” but also covers the here and now and looks forward. It is confident and in control.

We’re not just sharing what happened, but we’re owning and answering for what changes happened, what caused them, and using real campaign examples, competition, algorithm/platform changes, and talking about it connected with broader business implications and not just deep in search silos.

Leaving data up to interpretation can lead to a wide range of assumptions, and the data should not be left to speak for itself regarding what happened and why.

You don’t have to abandon slides or totally change your reporting format. However, you can change the order and only show the slides and metrics that tell a meaningful story and push deeper drill-down metrics that might be a distraction to hidden slides, linked reports, and things that you can have handy if needed, but that don’t create default distraction opportunities.

4. Connect Performance To Strategy

Performance data, no matter how real-time the dashboard is, how confident and positive the presentation or conversation might be, is typically delivered at a moment in time.

We all have short memories. If we’re in marketing leadership and close to the work within the team, we’re focused on the details of what we’re doing in the moment. For broader leadership outside of marketing, they are buried in their own day-to-day, and all of us likely don’t have our marketing strategy memorized.

Analytics should serve decision-making, and not simply be for a presentation. Framing data points in a decision-driven approach will shift the conversation and empower you in where you’re going with the digital strategy.

Having a documented, detailed, accountable, and actionable strategy and plan is critical. The next most critical thing is being able to connect what happened, where we are now, and where we’re going directly back to that strategy that was agreed upon in the past, as it is the objective source of truth to keep from chasing distractions or having debates about details that aren’t fully connected to the business outcomes we’re working toward with intention.

Marketing strategies and plans are often dozens of pages long in document format or sets of slides. They are rarely pulled up and walked through after the initial sign-off on the strategy. Bringing the strategy deck to every performance review meeting isn’t advised. However, having parts of it handy is important. It is easy to get lost on tangents about “what ifs” and disconnected tactics. With performance anchored to specific strategic initiatives, you can keep the strategy in front of stakeholders in context with performance data, so there are clear and objective details to stop tangents before they happen. Practically, this can be a strategic aspect of the plan right next to the KPI in a slide or in a dashboard to reduce the risk of data points being taken out of context.

5. Provide A Clear Point Of View

I would love to live in a world where search marketing and business numbers speak for themselves, and I could simply stand behind them. That world doesn’t exist, though, (I’ve learned the hard way), and if we don’t have a point of view to share on performance, rooted in the truths of our strategies and tactics, then we’re creating a vacuum for someone else to apply their own interpretations.

For a number of reasons, CMOs can “suffer from a crisis of confidence” and not fully own areas where they have a unique impact in the C-suite and beyond.

When it comes to digital marketing, we have to be confident about what is working, what isn’t working, and what needs to change. This is where we show up as leaders to own the subject matter. While we might need the approval of others, need their cooperation, or need to reach certain milestones, we want to avoid situations that put us in reporting mode, getting defensive, losing the message, and taking away from where we’re going.

Search marketing changes fast. I don’t have to tell you that. If you’re struggling with potentially coming across as defensive or if legit changes in the search industry risk sounding like excuses, I recommend developing your own POV on search. My team’s is 11 pages and is updated quarterly. It helps provide philosophical information about what we do in search, why, and references the third-party sources that go beyond our own experience to justify our strategies and tactics. This type of documentation can be helpful to offer to stakeholders for reading outside of performance reviews and to help extract things from inside your team’s heads out into the open that can be stood behind, challenged, or referenced to make things more objective and less personal when questions come.

6. Define What Happens Next

Whether in an informal conversation, a formal presentation deck, or providing context to a dashboard, you could have already addressed how the strategy is woven into the performance metrics and where we’re going next.

Being consistent in keeping everyone focused on the forward momentum (or corrections) of a plan incrementally in reporting or in conclusion, you don’t want to understate what is happening next.

Outlining next steps, priorities, adjustments, resources needed, and any strategic adjustments puts the focus on where you’re going, what you need to accomplish, and what to expect in the next review setting, especially if you tend to have your review (or reporting) derailed consistently by other stakeholders. This isn’t about closing the loop on what happened, but about closing the next loop and setting up the next review for meaningful impact, as MIT Sloan notes regarding how analytics success isn’t found in just data collection, but in proactive data management and insight.

Paid search benefits from being able to make quicker updates that effect change. But, both paid search and SEO can benefit from tangible action plans. While they are ongoing disciplines, treating short-term tasks like smaller projects or agile sprints can help connect activity to results. Crafting a brief, project plan, or documented sprint can go a long way in helping demonstrate the short-term activities that are planned, so there’s no wondering about what mystic or magical tactics are going to happen to ensure the conversation and review have progressed at the next interval for those who aren’t in the details with you.

Final Thought

In marketing leadership, it is on us to own our metrics and performance. That means going beyond the basics of simply reporting on the search marketing KPIs to stakeholders. It means demonstrating leadership in connecting the dots between search performance and business performance outcomes.

This is territory that, early in my career, I struggled with. How could I answer for things that happen beyond the conversation? Well, I had to learn through both wins and losses to understand it and grow comfortable with it.

Owning and leading in marketing, for search performance, means having the POV, connecting back to objective strategy anchors, and having a “review” mindset balanced with what happened, where we are, and where we’re going, and not getting stuck reporting the past or letting others control the narrative or come up with separate opinions that differ from the truth.

More Resources:

Featured Image: fotogestoeber/Shutterstock

Ecommerce MGMT 0 Comments
May 21 2026
Google Begins Rolling Out May 2026 Core Update via @sejournal, @MattGSouthern

Google has begun rolling out the May 2026 core update, according to the Google Search Status Dashboard

Google also announced the rollout on X through its Search Central account. The rollout may take up to two weeks to complete.

This is the second Search core update of 2026. The March core update finished rolling out on April 8 after 12 days.

What Google Said

As of publication, Google hasn’t published a companion blog post or shared specific goals for the May core update. The only official description so far is the dashboard entry, which states: “Released the May 2026 core update. The rollout may take up to 2 weeks to complete.”

That matches how Google handled the March core update, which also launched without a companion blog post. For that update, the company used the description “a regular update designed to better surface relevant, satisfying content for searchers from all types of sites.”

No new guidance came with today’s announcement.

Recent Update Timeline

About six weeks separate the completion of the March core update and today’s rollout. Here’s how the recent timeline looks.

This is the fourth confirmed Google ranking update of 2026 listed on the Search Status Dashboard, and the second Search core update this year.

Why This Matters

Some sites may see ranking movement over the next two weeks as the update rolls out. Don’t make content changes based on early ranking movement.

Wait at least one full week after a core update finishes before reviewing your Search Console data, per Google’s recommendation. Your baseline should be the weeks before May 21, compared against performance after the rollout completes.

Core updates aren’t targeted at specific types of content or policy violations. Pages can move up or down as Google updates its systems to keep pace with changes across the web.

Looking Ahead

No completion timeline has been shared beyond the two-week estimate. We’ll update this article when the rollout is confirmed complete.

Ecommerce MGMT 0 Comments
May 21 2026
LLM Guidance Doesn’t Transfer The Way SEO Guidance Did via @sejournal, @DuaneForrester

For roughly two decades, the SEO discipline operated on a quiet assumption that turned out to be one of its most valuable features. Guidance from one search engine traveled. If Google said sitemaps mattered, Bing said sitemaps mattered. If Bing said structured data deserved real effort, Google said the same. Practitioners optimized for Google with reasonable confidence that the work would carry across the other engines, and most of the time it did. That portability was not luck. It was the product of a structurally large overlap layer that the major search engines had jointly built, brick by brick, over twenty years.

That world doesn’t exist in LLM-land. The major providers train on different corpora, run different crawlers under different policies, route different queries through different retrieval systems, and apply different alignment processes that shape the final response in ways the upstream signals can’t predict. Guidance from any one provider, including Google’s guidance about its own Gemini products, is one data point. Practitioners carrying the SEO habit forward, the habit of treating one engine’s guidance as roughly the whole map, will optimize confidently for one platform and miss the others.

Sidebar: As I was finalizing this piece, Google published fresh guidance on optimizing for their generative AI features. Their framing is explicit: from Google Search’s perspective, optimizing for AI search is still SEO. That framing is accurate for Google Search. It does not extend to ChatGPT, Claude, Perplexity, or any other LLM, and that is precisely the trap this article is about.

The Shared Standards That Made SEO Guidance Portable

The era of portable guidance was built on actual collaboration, not coincidence. The Sitemaps protocol became the joint property of Google, Yahoo, and Microsoft in November 2006, when the three engines formally agreed to support a common protocol at version 0.90, building on Google’s earlier Sitemaps 0.84 from June 2005. Five years later, on June 2, 2011, the same three engines launched Schema.org, with Yandex joining shortly after, to create a common vocabulary for structured data markup. That was the announcement that got made on stage at SMX Advanced. I was on the Bing team at the time, and what struck me then is what still matters now. The engines were competitors, but they had decided that a shared vocabulary served them all. Webmasters got one set of rules. The web got cleaner data. The engines got better signals. Everybody won.

The pattern repeated with robots.txt, the 1994 convention that became RFC 9309 at the IETF in 2022, formalizing what every serious crawler already honored. And it repeated again, more recently, with IndexNow, the protocol Microsoft Bing and Yandex launched in October 2021. IndexNow is now supported by Bing, Yandex, Naver, Seznam, and Yep. Google has tested the protocol since 2021, but has not adopted it.

That overlap layer is exactly why Google’s guidance felt safe to follow, even if you cared about Bing traffic. The signals the engines used were not identical, but the inputs they accepted, the protocols they honored, and the standards they advertised were. Optimization had a shared substrate.

Where The LLM Stacks Actually Diverge

The LLM environment doesn’t have a shared substrate of comparable size. The differences are not cosmetic, and they are not temporary. They are baked into how the systems are built.

Start with training data. OpenAI has signed disclosed licensing deals with News Corp worth up to $250 million over five years, Axel Springer at roughly $13 million per year, Reddit at an estimated $70 million per year, plus the Financial Times, Condé Nast, Hearst, Vox Media, The Atlantic, the Associated Press, Le Monde, and others. Google has its own Reddit deal, estimated at $60 million per year, granting real-time data API access. Anthropic has not publicly disclosed equivalent publisher licensing deals, and that undisclosed status is itself the practitioner-facing point. The corpora that fed these models, and that continue to refresh them, are not the same documents. Practitioners cannot know what any given provider has paid for and what it hasn’t.

The crawler infrastructure diverges next. OpenAI runs three separate bots: GPTBot for training, OAI-SearchBot for search indexing, and ChatGPT-User for user-initiated retrieval. Anthropic runs three of its own: ClaudeBot for training, Claude-SearchBot for search, and Claude-User for user-initiated retrieval. Perplexity runs PerplexityBot and Perplexity-User. Google introduced Google-Extended in September 2023 as the user-agent that controls whether Google can use a site’s content to train Gemini, separate entirely from the Googlebot that handles traditional search indexing. There is no single AI user-agent. Every provider requires a separate rule, and the rules don’t translate cleanly across providers because the bots don’t do equivalent jobs in equivalent ways.

The retrieval architectures diverge structurally. ChatGPT has historically used Bing’s index as its primary web search source, and that connection appears to still be primary, though OpenAI continues to build out additional infrastructure alongside it. Perplexity built its retrieval system on a Vespa-based pipeline that treats documents and sub-document chunks as first-class retrievable units. Google’s Gemini uses Google’s own index plus Knowledge Graph grounding. Claude uses Brave Search as a retrieval partner. Same query, four different retrieval systems, four different views of which sources exist and which sources are worth surfacing.

Then comes the alignment layer, which is where SEO had no equivalent at all. After a model is trained on its corpus, providers run post-training to shape how the model actually behaves: tone, refusal patterns, format, safety posture, what counts as a good answer. OpenAI’s primary approach has been RLHF, or Reinforcement Learning from Human Feedback, where human raters score model outputs and the model learns to produce highly rated responses. Anthropic developed Constitutional AI, which trains models to critique and revise their own outputs against a written set of principles. These methodologies produce demonstrably different behavior in the final products. The same retrieved content, fed into two models aligned by two methodologies, can yield two materially different responses about the same brand.

When One Provider’s Guidance Demonstrably Fails To Port

The clearest single example of guidance that doesn’t port is llms.txt. Jeremy Howard of Answer.AI proposed the file in September 2024 as a markdown manifest, placed at a site’s root, that would guide LLMs to the most important content. The proposal got picked up across the SEO community. Yoast built a generator. Agencies added llms.txt creation to their service catalogs. Conference speakers declared it essential.

As of mid-2026, no major LLM provider has confirmed they consume the file. Not OpenAI. Not Anthropic. Not Google. Server-log analyses across hundreds of thousands of domains show major AI crawlers don’t routinely request /llms.txt at all. Google’s John Mueller publicly compared it to the deprecated meta keywords tag. Gary Illyes confirmed at Search Central Live in July 2025 that Google does not support llms.txt and is not planning to.

I’ve written about this elsewhere, so I won’t repeat the technicalities here. What matters for this argument is the structural lesson. Schema.org succeeded because three engines built it together and then enforced it together. Llms.txt was proposed by one researcher, picked up by tooling vendors, and ignored by the platforms it was supposed to serve. The shared-standards model that gave SEO its portable guidance is not available to LLM practitioners at the same scale, because the platforms are not building the standards together. They are building their own pipelines.

The Gemini Inversion

The cleanest illustration of how far guidance portability has degraded sits inside one company. Google publishes its own SEO documentation at Search Central, the canonical guidance the industry has followed for two decades. Those documents emphasize traditional ranking signals, E-E-A-T, content quality, technical accessibility, and structured data. That guidance is still useful for Google Search itself.

Google also makes Gemini, the model that powers AI Overviews and Google’s separate AI Mode surface. And the citation behavior of those surfaces does not appear to track the guidance the same company publishes for its own search results.

In late 2024, roughly three-quarters of pages cited in AI Overviews also ranked in Google’s top 12 for the same query. By early 2026, after Google upgraded AI Overviews to Gemini 3 in January, Ahrefs analyzed 4 million AI Overview URLs and found that only 38% of cited pages also appeared in the top 10 for the same query. A separate BrightEdge analysis put the overlap closer to 17%. SE Ranking’s post-upgrade work found that Gemini 3 replaced approximately 42% of the domains previously cited under earlier model versions and generates 32% more sources per response.

The gap widens further when you look at Google’s AI Mode, which is a separate conversational surface that runs on the same Gemini family. Semrush data shows AI Mode and AI Overviews reach semantically similar conclusions 86% of the time, but cite the same URLs only 13.7% of the time. Only 14% of AI Mode citations rank in Google’s traditional top 10.

It appears, so far, that the canonical relationship has shifted. Google’s published SEO guidance is still the cleanest path to ranking in Google Search. But that ranking is no longer a reliable proxy for being cited by Google’s own AI surfaces. The same guidance, the same content, the same domain, can produce three meaningfully different outcomes across Google Search, AI Overviews, and AI Mode, even though all three live inside the same company. The old playbook of following the search engine’s guidance and trusting that the engine’s other surfaces would behave consistently does not appear to be delivering the same returns it used to.

What Still Ports, And Why It’s Smaller Than It Looks

A universal layer does survive. Crawler accessibility still matters across every provider. Primary-source factual content still wins more citations than aggregator restatement. Clean retrievable structure still helps every system understand what a page is about. Presence on the high-authority sources that all major LLMs disproportionately cite, Wikipedia, YouTube, Reddit, major news outlets, still functions as a force multiplier across platforms. Earning visibility on those sources gives content a chance to surface in any LLM that draws on them.

But the universal layer is much smaller than it was in the SEO era. Qwairy’s analysis of 118,000 AI responses across ChatGPT, Perplexity, Google AI Mode, and Claude found that only 11% of cited domains appeared across multiple platforms. The other 89% were platform-specific. A brand that wins citations on Perplexity may be largely invisible on Claude. A brand that’s a regular reference on ChatGPT may not show up in AI Overviews at all. The same content can be the right answer for one system and the wrong answer for the system next to it.

What This Means For The Work

The practical implication is not abandoning all hope. It is that practitioners need to stop treating any single LLM provider’s guidance as the universal map and start treating it as one input among several. Read what every major provider publishes about their own systems. Test your visibility across platforms, not just on the platform you happen to use most. Treat divergence as the default and overlap as the exception, not the other way around.

This is not how SEO worked, and the difference matters. The old reflex was to optimize for Google and trust the portability. The new reality is that following one LLM’s guidance, even Google’s guidance about Gemini, will leave you optimized for a slice of the landscape and potentially blind to the rest. The discipline is being rebuilt on platform-specific work that didn’t exist in the SEO era, and the practitioners who recognize that first are going to spend the next two years setting the standards everyone else follows.

The overlap has shrunk. You now have more work than ever to accomplish.

If you have thoughts on where the divergence between providers is sharpest in your own work, reach out directly. I’d genuinely like to hear what’s showing up in the data.

More Resources:

This post was originally published on Duane Forrester Decodes.

Featured Image: Rawpixel.com/Shutterstock; Paulo Bobita/Search Engine Journal

Ecommerce MGMT 0 Comments
May 21 2026
How To Stress-Test A Staging Environment To Surface Risks Pre-Launch – Ask An SEO via @sejournal, @HelenPollitt1

This week’s Ask An SEO question:

“How do you stress-test a staging environment to surface SEO risks before a large-scale launch?”

It is one of the most important questions to answer when considering rolling out new websites, migrations, or significant changes to your live site.

First, let’s look at the difference between a “staging” site and the “production” site.

The staging site is often also called the “development” site, “pre-production,” or another name that is specific to your company. It is a test site that is meant to mirror your live site as much as possible to help developers test changes in a safe, private environment before launching them.

The “production” site is your live site. It’s the one that is accessible to the general public and should be operating as close to perfectly as possible.

There are some instances where developers might deploy straight to the production site without testing on a staging site first. For example, when there is no testing site to use, or there is no way of mimicking the conditions to test without deploying the change to the live site. This is risky to do. If a deployment breaks something else in the code, it could critically affect the usability of the live site.

How To Stress-Test The Staging Environment

As SEOs, it is very important that we test deployments that could potentially impact SEO performance before they launch. Oftentimes, we find ourselves discovering deployments after they have already started to affect traffic and rankings. This is less than ideal, as it can take a while for Googlebot to pick up changes once a bad deployment has been fixed. It is far better to test how Googlebot might process changes before it is able to do so.

Mirror The Production Site As Closely As Possible

The most important aspect of the staging site is that it is as close to the production environment as possible. This is critical because it enables any testing that you do to reveal the same outcome as if you had run the test on the production environment.

Any deviations between the two environments need to be cataloged. These discrepancies need to be communicated so that testers know to pay special attention to the areas of the production site that differ from staging. Once the deployment goes live, testers can quickly ensure these areas of the production site are behaving as expected.

Crawl The Site At Scale With Multiple User-Agents

One area that is often overlooked when stress-testing the staging environment is using several different user agents when crawling the site.

By using different agents, for example, mimicking Googlebot Smartphone and Googlebot Desktop, you are more likely to pick up technical issues with the site that aren’t obvious on first crawl. For instance, crawling as both desktop Googlebot and mobile Googlebot could show issues with rendering that are only occurring on mobile devices.

Make sure to crawl the site with user agents that are important for your specific industry. If you are targeting Google News as a channel, make sure to crawl the site as the Google-News bot. If images or videos are important to your SEO, crawl as Google-Image and Google-Video bots.

To put your staging site through its paces, make sure to crawl it with a mobile user agent, a desktop user agent, and spoof two search engine bots, e.g., Google and Bing. This way you are getting good coverage of the experiences of different, important bots. If possible, try to crawl as an LLM bot also.

Check The Rendering

A good starting point when testing a staging environment before a large-scale deployment is rendering. Modern websites will often use a lot of JavaScript, which, not inherently bad, can pose issues for some search bots in processing. For more information on how search bots process JavaScript, see this guide.

Set your crawling tool to include JavaScript rendering, and see what elements it can pick up. For example, can you see the header tags, meta title, schema markup? Then crawl the site again without JavaScript rendering enabled. Make sure those same elements are still available to the bots.

If in doubt, carry out some spot-checks on pages on the staging site. Inspect the Document Object Model (DOM) to see if the critical code elements are visible on first load of the page.

It is important that what you are seeing on the page is what the search bots are able to parse and render.

Test SEO Elements In Bulk And Across Page Types

Carrying out tests in bulk is important when testing a site before a large launch. When carrying out your tests, make sure they are across different page types and, if applicable, across languages.

If your site uses templates, make sure to test each of the templates that are critical to your SEO success. For example, on an ecommerce site, this means checking the category and product pages as a high priority.

For multilingual sites, ensure your tests are being run across different languages, and set a VPN to target the countries those languages are important for. Spoof those countries when running your crawls to make sure users will be seeing the correct language and content for their region. Although Googlebot frequently crawls from U.S.-based IP addresses, it also uses geo-distributed configurations, particularly for locale-adaptive or multilingual sites.

On your staging site, you may find that not all of the languages are represented, or perhaps there is a different localization process than what exists on production. This brings us back to the first point of needing the staging site to be as comparable to the production site as possible.

If it isn’t, in particular for localization elements, these need to be at the top of your post-deployment checks.

Benchmark Current Production Performance

A good aspect to remember is that your staging site may well be on a less performant server. This means that when conducting speed tests on staging, the results might be worse than if the tests were run on production. This can limit your ability to run meaningful checks before deployment.

To work around this, make sure to benchmark performance on production so that you can run the tests again quickly after deployment. This will mean waiting until the changes have gone live, but may be the only way to get an accurate understanding of areas like page load speed in situations where the staging server just isn’t as good as the production one.

Test For Edge Cases

Developers will try to break their code when testing it; we should too. When testing your staging site before deployment, run it through some edge cases. In practice, this means thinking of scenarios that, although unlikely, are possible. For example,

  • I am visiting the website from the U.S., but my language is set to French. What language are the meta tags in?
  • I am viewing the website on a mobile device but have the viewport set to desktop. What content am I able to access that I couldn’t on mobile otherwise?
  • If I turn JavaScript off, can I still use the menu drop-downs?

Test For Previously Known Issues

Make sure previous issues haven’t been reintroduced into the code during the most recent work. Even if the mass deployment is for a small area, such as a new meta title template being rolled out, that’s not to say issues aren’t being reintroduced elsewhere.

Don’t test only for the item being changed, but check across critical SEO areas. In particular, if work has been done recently to improve pages on the site, check those will still be in place with this latest deployment.

Equally, if there are known bugs that have affected your SEO performance in the past, check for these even if the deployment isn’t related to them. It’s easy for bugs to sneak back into code, especially if they have been there before.

More Resources:

Featured Image: Paulo Bobita/Search Engine Journal

Ecommerce MGMT 0 Comments