·8 min read·
Teams
Agencies
Workflow

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.com and https://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:

Example note: migrationsc-domain:acme.com: moved /blog/* to /articles/* with 301 redirects on 2026-08-12. Expect blog URLs to lose clicks and article URLs to gain them from that date. Compare by folder, not by URL.
Example note: brand termssc-domain:acme.com: brand queries are anything containing "acme", "acme app" or "acmeapp". Exclude them when reporting non-brand performance.
Example note: known tracking gapsc-domain:acme.com: the analytics tag was missing from checkout pages from 2026-06-03 to 2026-06-10. Search Console clicks for that week are fine; conversion data from analytics is not. Do not report that week's conversion rate as a drop.

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.

1. Striking-distance keywordsRead our notes for [property]. Then list queries at average position 6 to 20 with real impressions in the last 28 days, ranked by opportunity. For the top ten, name the page that ranks and one concrete change to that page.

More on this in striking-distance keywords.

2. Cannibalization checkRead our notes for [property]. Find queries where two or more of our pages split impressions in the last 90 days. For each, name the page that should own the query and what to do with the others: consolidate, redirect or differentiate.

More on this in keyword cannibalization.

3. Low-CTR pagesRead our notes for [property]. List pages with high impressions and CTR well below what their position suggests, last 28 days, excluding brand queries. Draft a better title and meta description for the top five.

More on this in low-CTR pages.

4. Content decayRead our notes for [property]. Compare the last 28 days with the same 28 days three months ago. List pages that lost the most clicks, separate ranking losses from demand losses, and ignore anything a note already explains.

More on this in content decay.

5. Weekly reportRead our notes for [property]. Compare the last 7 days with the 7 before: clicks, impressions, CTR and position, the top movers by clicks, and anything a note explains. Five bullet points, then one line on what to look at next.

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.

JobWhenWhoPromptOutput goes to
Weekly digestMonday morningRotates weeklyWeekly report (5)Team channel, plus a note for anything new
Client reportsFirst working day of the monthEach client's account leadWeekly report (5) on a 28-day window, plus content decay (4)Client email, reviewed before sending
Opportunity reviewEvery other WednesdayContent leadStriking distance (1), low CTR (3)Content backlog
Cannibalization checkMonthlyContent leadCannibalization (2)Content backlog
Technical sweepMonthlyRotates monthlyInspect top pages, sitemaps, PageSpeed, robots, redirects and TLSDev 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, free

Free plan included. See pricing