GoogleAgent-Mariner
Google's identity for its agentic browsing (Project Mariner), which drives a real browser to complete tasks a person asked for.
GoogleAgent-MarinerOfficial documentation: developers.google.com
See what GoogleAgent-Mariner sees on your site → try Peekabot, free
What GoogleAgent-Mariner does
GoogleAgent-Mariner is the fetcher identity Google introduced for Project Mariner, its AI agent that browses the web on behalf of paying users - loading pages in a real browser, executing JavaScript, filling forms, and clicking through multi-step flows the way a person would. Google has since folded it into the broader Google-Agent token on its crawler documentation, which covers agents running on Google infrastructure at a user's request; current logs show a full Chrome user-agent string containing Google-Agent, and Google publishes IP ranges for verification. Because Google classifies it as a user-triggered fetcher, its documentation says such fetchers generally ignore robots.txt - the fetch happens because a human asked for it.
Why it visits your site
A person told an agent to do something involving your site - compare prices, fill a form, look something up. Each visit is one user's errand, not a crawl.
The bigger picture: AI autonomous agents
Autonomous agents are what happens when the fetcher stops reading and starts doing. Where a user-agent fetcher retrieves one page to answer a question, an agent drives a real browser through a whole task someone delegated - comparing prices, filling a form, working through a checkout. It executes JavaScript, clicks, and navigates like a person, because functionally it is a person's errand wearing automation. The log signature is unlike anything else in this directory: browser-grade requests, human-shaped journeys, machine-grade patience.
The control story is still being written. Operators classify agents as user-triggered fetchers, which by long convention means robots.txt does not really apply - the same doctrine preview bots and feed fetchers have leaned on for years, now attached to software that can transact. Where operators publish IP ranges, verification is possible; where they don't, an agent is indistinguishable from a browser because it is one. For commerce sites especially, the question is shifting from "how do I block this" to "is my site legible to a machine that shops" - and the sites that answer it early will be the ones agents buy from.
Should you block it?
robots.txt is largely moot by Google's own account, so real control means server-level rules against the Google-Agent user agent or its published IP ranges. Think before pulling that lever: these visits are humans getting things done on your site through an agent, and turning the agent away turns the human away too. Sites with checkout or booking flows have the most reason to watch this traffic closely rather than block it outright.
Block via robots.txt
Add these lines to the robots.txt at your site root to ask GoogleAgent-Mariner to stay away:
User-agent: Google-Agent Disallow: /
Remember that robots.txt is a request, not a lock - compliance is voluntary, and enforcement happens at the server. Viz's AI Control pairs robots.txt rules with server-level 403 responses and then probes your site to verify the block is actually holding.
How to see GoogleAgent-Mariner traffic on your site
You have three windows onto it, each with a catch. Raw hosting access logs contain every GoogleAgent-Mariner request, but many managed WordPress hosts don't expose them, and when they do you are grepping text files by hand. A CDN dashboard sees the traffic at the edge, but it lives outside WordPress and speaks in totals, not in your site's terms. And JavaScript analytics - GA4 and friends - will never show it at all, because GoogleAgent-Mariner doesn't run scripts.
Viz's answer is the request log: filter to GoogleAgent-Mariner and read exactly which URLs it fetched and when, right inside wp-admin - then watch the same filter after any blocking decision to see whether the visits stopped, slowed, or kept coming.