AI Agents Will Browse Like Humans—Until Protocols Win: What Businesses Must Do Now To Stay Visible
Google’s CEO expects AI agents to reach websites in two ways: by browsing pages like humans and by using emerging protocols built for agents. That split creates immediate operational risk (analytics, access control, conversion paths) and a longer-term standards race (commerce, booking, identity, permissions). Here’s what changes, why it matters, and a practical action plan to prepare—without waiting for the “perfect protocol.”
AI agents are moving from “answering questions” to “doing the work.” And that shift forces every business to confront a practical reality: agents still have to reach your website (or your data) before they can buy, book, schedule, compare, or recommend.
In an interview covered by Search Engine Journal, Google CEO Sundar Pichai described two expected paths for agents to access websites:
- Browsing pages (clicking through like a human would)
- Using protocols purpose-built for agents (a more scalable approach, but slower to develop)
That is not just a technical footnote. It’s the new operating environment for visibility, Attribution, conversion, and—yes—ads economics. If your site is hard for humans to use, it will be hard for browsing agents. If your business depends on fragile UI patterns, agents will break them at scale. And if you wait for protocols to mature before you act, you’re going to spend the next 12–24 months reacting to surprises you could have prevented.
This editorial lays out what changed, why it matters, what can go wrong, and an action plan for SMEs, ecommerce teams, publishers, and agencies—plus how AYSA fits as an execution system that monitors, prepares changes, asks for approval, and executes accepted improvements.
Concise summary
- Two access modes will coexist: agents that browse pages and agents that use protocols/APIs.
- Browsing agents create near-term risk: UX blockers, JavaScript dependencies, identity issues, and measurement gaps.
- Protocols are the long-term path to scale: more reliable transactions, clearer permissions, better interoperability—eventually.
- Businesses should prepare now: harden Crawlability and usability, build agent-friendly content and Structured data, and fix analytics to detect “agent-shaped” traffic.
- Execution will be the differentiator: the winners will be the teams that can ship improvements safely and continuously, not the teams with the best strategy deck.
Key takeaways (what to do in the next 30–90 days)
- Make critical journeys resilient: product discovery → price → availability → checkout/lead form must work without gimmicks, excessive pop-ups, or brittle scripts.
- Stop hiding core info behind interactions: shipping, returns, location, hours, eligibility, pricing ranges—put it in HTML and structured formats.
- Measure what you can: update analytics and server logs processes so you can identify agent activity and separate it from “direct.”
- Prepare for protocol adoption: inventory cleanliness, consistent IDs/SKUs, well-structured offers, and accurate business rules are the prerequisites.
- Implement an execution loop: Monitoring → prioritized recommendations → approvals → safe deployment. That’s the gap AYSA is built to close.
Table of contents
- What changed: why Pichai’s “two ways” matters
- The two lanes of agent access: browsing vs. protocols
- Why this matters right now (even before protocols mature)
- What breaks when agents browse your site (even if rankings don’t change)
- Robots.txt, permissions, and the uncomfortable truth about “user-triggered” fetching
- Measurement reality: when “the user” isn’t a person with a browser
- The protocol future: why it scales better (and why it won’t save you this quarter)
- The ads question nobody answered (and what to plan for anyway)
- A concrete SME scenario: the hotel booking problem (and how to fix it)
- What agencies must rethink: deliverables, not decks
- The practical action plan: hardening for browsing agents + prepping for protocols
- Where AYSA fits: monitoring, approvals, and execution at scale
- What to do next (checklist)
- Sources and further reading
What changed: why Pichai’s “two ways” matters
For years, “AI in search” mostly meant better ranking systems and better answers. The user still clicked (or didn’t), and your job was to win that click. Now, we’re entering a new stage: an agent can decide to click for the user, navigate for the user, and complete actions for the user.
Pichai’s framing—agents reach websites either by browsing pages or by using protocols—should be read as a roadmap for the next generation of web traffic:
- Browsing agents are the “right now” reality. They operate in today’s messy web.
- Protocols are the “future standard,” but standards take time, incentives, and coordination.
If you run an SME, the immediate question isn’t “Which one will win?” It’s: What happens to my revenue while both are true?
If you run an agency, the immediate question isn’t “How do I pitch agent optimization?” It’s: How do I reliably ship changes that improve outcomes while the landscape is unstable?
That’s why this matters: it’s not one migration. It’s two concurrent systems with different failure modes.
The two lanes of agent access: “browser clicks” vs. “protocols”
Let’s strip away the hype and translate this into business language.
Lane 1: Agents browse pages (like humans)
This is the “computer use” path. The agent loads pages, Clicks buttons, fills fields, and attempts to complete tasks. It’s similar to what a human does—but it is less tolerant of ambiguity and more likely to fail silently if:
- Elements change location
- Forms require complex validation
- Pop-ups block interaction
- Consent flows aren’t handled cleanly
- Login is required without clear API fallback
In the SEJ coverage, Google identifies a browsing user agent called Google-Agent for hosted agents navigating the web upon user request. SEJ notes Google categorizes these as “user triggered fetchers,” which has implications for Robots.txt expectations. That’s a big deal operationally, and we’ll come back to it.
Lane 2: Agents use protocols (agent-ready standards)
This is the “structured handoff” path. Instead of clicking through your UI, the agent uses a standardized protocol to request actions and receive structured responses: product data, availability, price, booking rules, cart transfer, confirmations, etc.
In SEJ’s reporting, Google has backed a commerce-oriented protocol effort called the Universal Commerce Protocol (UCP), positioned as an open standard to enable agentic actions in Google experiences such as AI Mode and Gemini.
Protocols are generally more scalable because they:
- Reduce UI fragility
- Standardize identity, permissions, and transaction steps
- Make it easier to handle edge cases consistently
- Enable interoperability across many vendors
But they also require adoption, governance, and real incentives—meaning they arrive unevenly across industries.
Why this matters right now (even before protocols mature)
Many businesses will hear “protocols will scale better” and interpret it as “I’ll wait until this is standardized.” That’s the wrong move for three reasons.
1) Browsing agents will be the bridge technology
Pichai’s point (as reported by SEJ) is that browsing stays in the picture while protocols evolve. So browsing is not a brief experiment—it’s an interim default.
2) Browsing exposes your conversion path as an operational dependency
In classic SEO, a messy site could still rank. You might leak conversions, but you could “make it up in volume.” Agent browsing flips that: the agent is effectively an impatient power user. If the journey breaks, you don’t just lose conversion—you may lose the recommendation, the inclusion, or the completion of the task entirely.
3) Protocol readiness depends on fundamentals you should fix anyway
Protocols won’t magically clean up inconsistent inventories, unclear policies, or contradictory business rules. If your product feed conflicts with your site, or your booking rules aren’t explicit, protocols will amplify the confusion faster than browsing ever could.
What breaks when agents browse your site (even if rankings don’t change)
When AI teams say “agents will browse,” business owners imagine a smarter customer. The reality is closer to: a relentless intern with perfect memory and zero patience.
Here are the failure points that matter most for SMEs.
Pop-ups, cookie walls, and interstitials
If an overlay blocks content or buttons, an agent may stall. Even if it can theoretically click “Accept,” the variation across consent tools, regions, and device sizes makes this fragile.
What to do: Keep consent UX minimal, predictable, accessible, and avoid stacking modals (newsletter + discount + consent) at page load.
JavaScript-only content and interaction-dependent details
If your shipping costs, availability, or pricing only appears after a sequence of interactions, you’re betting that the agent will replicate that perfectly.
What to do: Put essential decision data in the rendered HTML and use structured data where appropriate. Remove “mystery steps.”
Login walls for basic tasks
If an agent can’t access return policies, pricing tiers, appointment rules, or even inventory states without logging in, it will either abandon—or provide an inferior answer based on partial info.
What to do: Decide what should be public (and indexable) versus private. Make that boundary intentional.
Accessibility and semantic structure problems
Agents navigating a DOM still benefit from clean semantics. Missing labels, inconsistent Heading structure, and unclear button names don’t just hurt accessibility—they create ambiguity for automation.
What to do: Treat accessibility improvements as agent-readiness improvements. (This is one of those rare “do the right thing” tasks that also boosts performance.)
Broken internal search and filters
If your on-site search produces inconsistent results, or filters break on mobile, agents will struggle to find the correct product/service variant efficiently.
What to do: Test internal search like it’s a revenue channel. Because it is.
Robots.txt, permissions, and the uncomfortable truth about “user-triggered” fetching
One of the most operationally important details in the SEJ piece is the distinction between classic crawlers and “user-triggered fetchers.” SEJ reports that Google’s hosted browsing agents use a Google-Agent user agent and may not follow robots.txt directives because the fetch is user-requested.
This is a fundamental shift in the mental model many site owners rely on:
- Robots.txt was never an access control system; it’s a crawler directive standard.
- If an agent is acting “on behalf of a user,” blocking it via robots.txt may not work—or may not be honored the same way.
So what should you do?
Revisit what you’re trying to control
- If the goal is to protect private data, you need authentication and authorization, not robots.txt.
- If the goal is to prevent automated abuse, you need rate limiting, bot management, and fraud controls—while avoiding blocking legitimate users.
- If the goal is to manage content visibility, use indexation controls, canonicalization, and consistent site architecture—paired with clear public content pages.
Expect identity and disclosure conflicts
SEJ’s summary references Amazon blocking a shopping agent that didn’t identify itself when browsing. Whether you agree or not, that’s the market reality: businesses will push back when automation creates costs without clear benefits.
My take: the “agent identity” debate is going to become as important as the “crawler identity” debate, but more heated—because agents don’t just read, they act.
Measurement reality: when “the user” isn’t a person with a browser
Most SMEs already struggle to answer a simple question: “What generated this lead or sale?” Now add agents, and the problem gets worse.
Three measurement issues will show up quickly:
1) Misattribution (agent traffic looks like “direct”)
If an agent opens pages server-side, uses unusual fetch patterns, or strips referrers, your analytics may bucket it incorrectly. That means you can’t connect cause → effect, which means you can’t prioritize fixes confidently.
2) Funnel fragmentation
An agent might read your content in one environment and complete an action in another. That breaks the classic linear funnel assumptions.
3) Conversion ambiguity
If an agent fills forms or schedules appointments, who is the “user” in your CRM? What happens if the agent made a wrong selection? What happens if it repeats attempts and creates duplicates?
Actionable move: start treating server logs and event instrumentation as first-class growth tooling, not IT trivia. Even if you don’t have perfect agent detection, you want the ability to investigate anomalies quickly.
AYSA’s emphasis on monitoring exists for exactly this reason: when the environment shifts, you don’t need more opinions—you need earlier detection and a cleaner path to changes you can approve and ship.
The protocol future: why it scales better (and why it won’t save you this quarter)
Protocols are attractive because they promise a world where agents don’t have to “pretend” to be users clicking UIs. Instead, they can request the business outcome directly.
As reported by SEJ, Google has been involved in a commerce-oriented standard effort called the Universal Commerce Protocol (UCP), aimed at enabling agentic commerce actions in Google’s AI experiences.
Conceptually, that’s the right direction. Here’s why.
Protocols reduce UI risk
Your UI can change weekly without breaking agent integrations—because agents rely on stable definitions, not pixel positions.
Protocols create explicit permissions
A protocol can incorporate authentication, user consent, scope, and revocation in a way that UI scraping never can.
Protocols create consistent outcomes
With protocols, you can validate business rules once (availability, substitution rules, shipping constraints) instead of hoping each agent “does the right thing” through your UI.
But here’s the caution: protocols require:
- Widespread adoption
- Cross-industry agreement
- Ongoing governance
- Clear value exchange for merchants
That’s why Pichai’s view—protocols scale better but take longer—rings true. The web doesn’t standardize quickly when money is involved.
The ads question nobody answered (and what to plan for anyway)
SEJ notes that Pichai was asked about protecting Google’s interfaces and the implication for engagement-driven ad models when agents do the browsing. The reported response emphasized “put users first” and acknowledged shifting equilibria—but it didn’t answer the concrete question of how ads work when an agent is doing the navigating.
You don’t need a definitive ad blueprint from Google to plan. You need scenarios.
Scenario A: Ads remain, but move up the decision chain
Instead of buying attention (clicks), advertisers buy inclusion at the agent’s decision point—recommendations, comparisons, shortlists.
Scenario B: Ads become outcome-based or protocol-based
If protocols govern transactions, advertising may look more like placements in a marketplace with explicit rules and attribution.
Scenario C: Fragmentation
Different verticals settle into different equilibria. (This is likely.) Travel, local services, ecommerce, and SaaS will not converge neatly.
Business takeaway: strengthen the parts you control regardless of ad model:
- Clear offers
- Trust signals
- Fast, reliable pages
- Accurate structured data
- Measurable conversions
A concrete SME scenario: the hotel booking problem (and how to fix it)
Let’s make this real.
Imagine a 40-room boutique hotel. Today, customers might:
- Search “hotel near [venue] with parking”
- Browse photos
- Compare rates
- Book directly or via an OTA
Now add agents.
What the agent tries to do
The user says: “Book me a king room under $250, free cancellation, parking, arriving Friday.” The agent attempts to complete that.
Where browsing breaks
- A date picker widget fails under automation
- Parking info is hidden in an accordion below the fold
- Cancellation terms are in an image or PDF
- The mobile experience is different from desktop
- A chat widget covers the “Book” button
Business impact
The agent may:
- Book the wrong rate
- Abandon and choose a competitor
- Recommend an OTA listing instead (higher fees for the hotel)
How you fix it (without waiting for protocols)
- Make policies parseable: cancellation and parking details in clean HTML, not just images.
- Reduce overlays: limit pop-ups on core booking pages.
- Stabilize the flow: ensure date selection and room selection are consistent and accessible.
- Expose essentials: rates, fees, parking, check-in/out, and restrictions clearly on the primary pages.
How you prep for protocols
- Clean inventory rules: define room types, rate plans, restrictions, and fees consistently.
- Normalize naming: avoid 12 variants of “King Deluxe (Ref)” across systems.
- Document business logic: what counts as free cancellation, what are blackout conditions, etc.
This is the “agents browse now, protocols later” reality. If you harden the user journey today, you win twice: higher human conversion and higher agent success.
What agencies must rethink: deliverables, not decks
Agents change the client-agency contract in a subtle way: more outcomes depend on what happens after the impression.
Traditional deliverables—keyword maps, content calendars, audits—are not enough if execution is slow. In an agentic world, small UX/technical failures can nullify the best visibility gains.
Agencies should shift toward:
- Operational SEO / AEO / GEO: ongoing fixes, testing, and iteration
- Technical hygiene as a product: performance, accessibility, structured data, clean templates
- Measurement discipline: server logs, event tracking, anomaly detection
- Change management: approvals, staging, rollback plans
This is exactly why we position AYSA as an execution system—not a reporting tool. The market is full of insights. The shortage is safe shipping.
The practical action plan: hardening for browsing agents + prepping for protocols
Here’s a pragmatic plan you can implement without guessing future standards.
Step 1: Map your “agent-critical” journeys
Pick 2–3 journeys that matter to revenue:
- Ecommerce: category → product → cart → checkout
- Local service: service page → quote request → scheduling
- Clinic: provider page → insurance info → appointment request
- Publisher: article → newsletter signup → subscription
Then ask a blunt question: Can a determined stranger complete this with zero context and zero patience? If not, fix that first.
Step 2: Remove “invisible” blockers
- Excessive pop-ups
- Scrolljacking and unusual interaction patterns
- Auto-redirects that break back navigation
- Client-side rendering that delays core info
Step 3: Make key facts explicit and consistent
Agents don’t just need content; they need decision data:
- Price ranges and fees
- Availability rules
- Shipping and returns
- Service area
- Booking policies
Put those in clean on-page copy where it belongs. That’s basic AEO/GEO hygiene. If you want a starting point for how we think about this at AYSA, see AI search visibility.
Step 4: Treat structured data as a reliability layer
Structured data is not a guarantee, but it is a consistency mechanism. If your human-readable page and your structured markup disagree, you’ll create agent confusion at scale.
Rule: only mark up what is true, stable, and supported by your visible page content.
Step 5: Improve technical resilience (speed + accessibility + stability)
Agent browsing doesn’t eliminate the need for technical SEO—it raises the bar. If your site is slow or unstable, you force the agent to time out, retry, or abandon.
That’s why “technical SEO” is not a nice-to-have. It’s revenue protection.
Step 6: Upgrade measurement and investigation capability
- Make sure you can access server logs (or at least CDN logs)
- Define a process for investigating traffic anomalies
- Ensure critical events are tracked (leads, add-to-cart, checkout steps)
Even without perfect identification, better observability makes you faster and calmer when the ecosystem changes.
Step 7: Prepare internally for protocols (without chasing every standard)
Most businesses will not “implement protocols” tomorrow. But you can prepare by making your business data clean:
- Consistent SKU/offer IDs
- Accurate inventory rules
- Clear policies
- Fewer exceptions and one-off hacks
That’s how you become protocol-ready without making bets you can’t justify.
Where AYSA fits: monitoring, approvals, and execution at scale
Most teams don’t fail because they lack ideas. They fail because they can’t execute improvements fast enough—and safely enough—across content, templates, and technical foundations.
AYSA is built as an execution system for SEO/AEO/GEO:
- Monitors your site and search visibility signals (Monitoring)
- Prepares recommended changes (technical and content)
- Asks for approval so humans stay in control
- Executes accepted changes to remove backlog friction
In an “agents browse now, protocols later” era, that workflow matters because:
- You’ll need continuous fixes (not quarterly audits)
- You’ll need fast iteration on pages that agents touch
- You’ll need governance (approvals) to avoid risky automation
If you’re evaluating what this looks like in practice, start with AYSA’s AI SEO tools, then review pricing for the operational model. For ongoing implementation notes and playbooks, we keep building in the AYSA blog.
What to do next (checklist)
Use this as a practical next-step list for the next two weeks.
- Pick one revenue-critical flow (checkout, booking, lead form) and do a “friction audit” focused on overlays and required interactions.
- List the top 10 facts customers need to decide (price, availability, policies). Confirm they are visible, consistent, and not hidden behind accordions that fail.
- Run a technical sanity pass: performance basics, accessibility labels, broken internal search/filtering, mobile issues.
- Confirm you can investigate traffic anomalies: access logs, track key events, and document a process.
- Identify what must never be automated (pricing changes, policy changes, legal pages) and set approval gates.
- Set up an execution loop: monitoring → prioritized backlog → approvals → deployment → learnings.
Sources and further reading
- Search Engine Journal: Pichai Says AI Agents Will Click Through Pages And Use Protocols (primary research input for this editorial)
- Search Engine Journal: AI Search coverage (context on ongoing AI search developments)
- Search Engine Journal: Technical SEO (additional background on technical foundations relevant to agent browsing)
- Search Engine Journal: SEO (broad SEO context as search behavior evolves)
- Search Engine Journal: Paid Media (for watching how monetization models shift alongside agent behavior)
Related AYSA resources:
Author: Marius Dosinescu, AYSA.ai
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
