How SEO teams work with AI
Give every teammate’s AI the same Search Console data and the same notes. Roles, routines, a shared prompt library and guardrails for SEO teams using AI.
An SEO team gets consistent answers from AI when every teammate's assistant reads the same Search Console data and the same written context, and when the team runs the same prompts on a fixed rota. This guide covers the four pieces: one data source, shared notes as team memory, a shared prompt library, and guardrails that keep a person in charge of every change to the site.
The problem: five people, five different answers
Picture a Monday. Traffic to a client's blog fell last week, and five people on the team ask their AI why. One pastes a CSV export from Search Console into ChatGPT. One asks Claude with no data at all and gets a confident list of generic causes. One uses a third-party rank tracker with its own keyword set. One remembers the site moved its blog to a new folder in August; the other four do not. The fifth asks about the wrong property, because the client has both a domain property and a URL-prefix property.
Five people, five answers, and a client call at eleven. None of it is the AI's fault. Each assistant starts every conversation from nothing: it does not know which property matters, which dates were migrations, which queries are brand, or that the analytics tag was broken for a week in June. Whatever one teammate explained to their AI on Friday is gone by Monday, and it never reached anyone else's AI in the first place.
So the fix is not a better model. It is giving every assistant the same two inputs: the same live data, and the same context about what that data means.
Give every AI the same data
The first input is the data itself, read live from Google rather than from whatever export someone happened to download. A remote MCP server does this: each teammate adds one URL to the AI client they already use, and their assistant can call Search Console directly. With the Google Search Console MCP server that URL is https://mcpsearchconsole.com/mcp, and it works in Claude (claude.ai, the desktop app and Claude Code), ChatGPT through a Developer mode connector, Grok Bot, Cursor, Codex and any other client that speaks remote MCP. Mixed tools are fine: Ana can live in Claude while Ben lives in ChatGPT, and they still query the same source.
The detail that matters for a team is how people sign in. Each person connects with their own Google account. Nobody shares a login, nobody pastes a service-account key into a group chat, and there is no "SEO team" Google account whose password lives in a spreadsheet. Each teammate's AI sees exactly the Search Console properties that teammate's Google account can see, no more.
That gives you access control you already understand. To give someone a client, add their Google account as a user on that property in Search Console. When they move off the account, remove them there, and their AI loses the property too. When someone leaves the company and their work account is closed, their access ends with it.
Two habits keep it shared:
- Name the exact property.
sc-domain:example.comandhttps://example.com/are different properties with different numbers. Pick one per client and write it down (the next section shows where). - Use the same windows. Search Console data trails by about two days, so "yesterday" is usually empty. Agree on trailing windows, such as last 7 days against the 7 before, or last 28 against the 28 before, and use them everywhere.
Give every AI the same context
Data without context is where the five different answers came from. The second input is a set of short, shared notes that every assistant reads before it analyses anything. Search Console MCP has three tools for this: add_note, list_notes and delete_note. Notes are stored on mcpsearchconsole.com (never in Google), can be scoped to one property or apply account-wide, and cost nothing against the data-pull quota. On the Team plan they are shared: everyone on the team sees every note, each note is labelled with its author, and the plan owner can delete any of them.
Treat notes as the team's memory. Good notes are one fact each, dated, and written so a stranger could act on them. Three examples:
Then make reading the notes the first step of every prompt the team uses: "Read our notes for this property, then..." When a traffic drop lines up with a migration date, the assistant says so, whoever is asking. When someone learns something new (a client changed their CMS, a section was noindexed on purpose), they ask their AI to save it as a note, and from then on every teammate's AI knows it too.
Prune as you go: a note that no longer applies is noise. Notes hold up to 2,000 characters each and 200 per account, plenty for facts.
A shared prompt library
The third piece is a short list of prompts the whole team runs the same way. Same wording, same windows, same output shape. When two people run the same prompt on the same property with the same notes, they should get the same answer, and a reviewer can compare this week's output with last week's without translating between styles.
Keep the library somewhere everyone already looks (a pinned doc, a wiki page, a project in your AI client). Five prompts cover most weekly SEO work; each links to a use-case page with more detail.
More on this in striking-distance keywords.
More on this in keyword cannibalization.
More on this in low-CTR pages.
More on this in content decay.
More on this in the weekly SEO report.
Two rules keep the library useful. Change a prompt in one place, and tell the team when you do. And when a prompt keeps producing a wrong answer because the AI is missing a fact, fix it with a note, not with a longer prompt.
Who runs what
Shared data and shared prompts still need owners, or every job is done twice or not at all. A simple weekly rota works for most teams: one person per job, rotating so nobody owns the boring one forever. The jobs below are the ones that benefit most from a regular rhythm.
| Job | When | Who | Prompt | Output goes to |
|---|---|---|---|---|
| Weekly digest | Monday morning | Rotates weekly | Weekly report (5) | Team channel, plus a note for anything new |
| Client reports | First working day of the month | Each client's account lead | Weekly report (5) on a 28-day window, plus content decay (4) | Client email, reviewed before sending |
| Opportunity review | Every other Wednesday | Content lead | Striking distance (1), low CTR (3) | Content backlog |
| Cannibalization check | Monthly | Content lead | Cannibalization (2) | Content backlog |
| Technical sweep | Monthly | Rotates monthly | Inspect top pages, sitemaps, PageSpeed, robots, redirects and TLS | Dev ticket for anything that regressed |
The technical sweep is the one job that is not in the prompt library above, because it is less about analysis and more about checking: inspect_url on the most-clicked pages, list_sitemaps for errors, page_speed on key templates, and the free health checks (check_robots, check_redirects, check_tls). The technical SEO audit page has a full version.
Some of these jobs can run on a schedule with no one at the keyboard. Our guide to scheduling SEO checks in Claude Code and ChatGPT covers that, but keep a named person on the rota even then: someone has to read the output and decide what happens next.
Guardrails
AI on a team raises a fair question: what can it actually change? Two rules answer it.
Read-only access. When each person signs in, Google is asked for read-only Search Console access (the webmasters.readonly scope). Nobody's assistant can change a property's settings, remove URLs or alter anything in Search Console. Search Console reports are fetched live from Google and not stored on our servers. The one write in Search Console that exists, submitting or deleting a sitemap, is a separate opt-in that each person has to grant for themselves; leave it off unless someone on the team specifically needs it. Notes are the only thing assistants write by default, and they live on mcpsearchconsole.com, not in Google.
A person approves every change to the site. The AI reads data and recommends; a named person decides and ships. In practice:
- Recommendations go into the backlog or a ticket, never straight into the CMS.
- Title and meta rewrites are drafts. A person edits and publishes them.
- Client-facing reports are reviewed by the account lead before they go out. The AI drafts the email; a person sends it.
- Redirects, noindex tags and robots.txt changes always go through whoever owns the site's code, with a note saved afterwards so the next analysis knows the change happened and when.
That last habit closes the loop. Every change a person ships becomes a dated note, so in four weeks, when someone asks "did the new titles work?", every teammate's AI can line the numbers up against the change date without anyone remembering it.
Setting it up for a team
The Team plan is built for exactly this setup:
- 29.99 € a month excluding VAT, flat: unlimited people, data pulls and properties.
- Anyone who signs in with an address on a verified domain (subdomains included) is covered automatically, with no seats or invites, and each person still sees only the properties their own Google account can see.
- Notes are shared across the team, labelled with each author, and the plan owner can delete any of them.
To start, sign in with your work Google account and choose Team on your account page. If your company uses Google Workspace, the domain verifies as you sign in; otherwise you add one DNS TXT record. Then send the team the server URL and the link to your prompt library, and write the first three notes together. The full details, including how existing Solo subscriptions and freelancers on personal addresses are handled, are on the Search Console MCP for agencies page.
Ready to put your search data in your AI?
Set up the Search Console MCP, freeFree plan included. See pricing