Why do SEO checks in your editor
Developers and indie hackers usually hear about SEO problems weeks late, from a marketer or from a traffic chart. By then the commit that caused it is buried. Bringing Search Console data into your coding agent shortens that loop to minutes.
- Your agent can read the code that renders the page and Google’s report on that page in one context.
- You can verify a fix against real index data instead of guessing.
- You stop switching between the Search Console UI, the browser and your editor.
Setup in two minutes
- Sign in, connect the Google account that has access to your Search Console property, and optionally Bing.
- Create an API key on the dashboard setup page.
- Add a remote server named
gscmcpserverto~/.cursor/mcp.json(Cursor) or.mcp.json(VS Code), with your endpoint as the URL and anAuthorization: Bearerheader. - Enable the tools in your agent’s tool settings.
Full client-by-client instructions, including Claude Code, Codex and Gemini CLI commands, are in the connection guide.
URL Inspection from the agent
The inspect_url tool calls Google’s URL Inspection API and returns the same information as the inspection panel in Search Console: index verdict, coverage state, last crawl time, the user-declared and Google-selected canonicals, robots.txt state, and detected rich results.
Inspect https://example.com/pricing. Is it indexed? When was it last crawled? Did Google accept our canonical? Are any rich results detected?
The property is detected automatically from the URL, so you do not need to remember whether it is a domain property or a URL-prefix property.
Reading the verdict
| Coverage state | What to look at in code |
|---|---|
| Excluded by ‘noindex’ tag | Meta robots in layouts, environment-based flags, X-Robots-Tag headers |
| Blocked by robots.txt | Generated robots rules, staging rules leaking to prod |
| Duplicate, Google chose different canonical | Canonical tag logic, trailing slashes, query parameters |
| Page with redirect | Middleware, redirects config, locale routing |
| Crawled – currently not indexed | Thin or duplicate templates, client-only rendering |
| Soft 404 | Empty states returning 200, missing data fallbacks |
Canonical mismatches
A Google-selected canonical that differs from yours is one of the most common silent bugs. Typical causes in code:
- Canonical built from the request URL, including parameters.
- Mixed trailing-slash behaviour between links and canonicals.
- Locale or region routes that canonicalise to the wrong language.
- Pagination pages canonicalising to page one.
Inspect these 10 product URLs and list any where the Google-selected canonical differs from the declared one. Then find where we set the canonical in this codebase and explain why they could differ.
Duplicate pages also cause keyword cannibalization, so a canonical bug often shows up as two URLs splitting rankings.
Sitemap health
The list_sitemaps tool returns sitemaps submitted to Google and feeds submitted to Bing, with last submission and download times, errors, warnings and submitted vs indexed counts where the provider reports them.
List my sitemaps in Google and Bing. When was each last downloaded? Any errors? Compare the submitted URL count with the number of routes our sitemap generator should produce.
- A “last downloaded” date that stopped moving suggests the sitemap URL now errors or redirects.
- Submitted counts far below expectations point to a generator bug or a build-time data fetch that failed.
- Indexed far below submitted points to quality or duplication, not the sitemap itself.
For Bing, enable IndexNow on deploy so changed URLs are picked up quickly. See Bing and AI search visibility.
Post-deploy checks
After a release that touches routing, layouts, metadata or middleware, spend two minutes checking production:
We just deployed changes to the blog layout. Inspect the blog index and three blog posts. Confirm each is indexable, the canonical is correct, and robots.txt allows it. Then compare clicks for /blog/ pages over the last 7 days with the 7 days before.
Remember that inspection reflects Google’s last crawl, not your latest deploy. A freshly fixed page can still show the old state until it is recrawled; request indexing in Search Console to speed that up.
From finding to fix in the same session
The real advantage is continuity. The agent that found the problem can open the file that caused it.
- Ask the agent to inspect the affected URLs.
- Ask it to locate the code that renders the relevant tag or response.
- Review and apply the fix, then add a test if you can.
- After deploy and recrawl, ask it to inspect the URLs again and compare clicks before and after.
If the bug already cost traffic, the traffic drop diagnosis guide helps you measure the damage and the recovery.
Example: a Next.js app
In a Next.js App Router project, SEO-relevant code tends to live in a handful of places. Point your agent at them:
metadataandgenerateMetadataexports for titles, descriptions, canonicals (alternates.canonical) and robots.app/robots.jsandapp/sitemap.jsfor crawl rules and sitemaps.middlewareandnext.config.jsredirects for locale and trailing-slash behaviour.metadataBasein the root layout, which turns relative canonicals into absolute URLs.
Search Console says /docs/getting-started has a Google-selected canonical of /docs/getting-started/. Check our metadata, trailingSlash setting and links in this repo and propose a consistent fix.
Quotas and limits
- URL Inspection: about 2,000 calls per property per day and 600 per minute.
- Inspection data reflects the last crawl, not live HTML. It cannot test unpublished pages.
- Performance data lags two to three days and goes back 16 months.
- Every tool call counts toward your plan’s monthly allowance; batch related checks with
multicall.
Building a product on your own? The weekly founder routine pairs well with these deploy checks.
Frequently asked questions
Can the agent request indexing in Google?
No. Google’s URL Inspection API is read-only, and GSC MCP Server only requests read access. Request indexing manually in Search Console after you ship a fix.
What is the URL Inspection API quota?
Google allows about 2,000 inspections per property per day and 600 per minute. Inspect representative URLs from each template rather than whole sites.
Does this work with Claude Code and Codex too?
Yes. Any MCP client that supports remote HTTP servers works, including Claude Code, Codex, Gemini CLI, Windsurf and Cline. The prompts in this guide are client-agnostic.
Is it safe to put my API key in .cursor/mcp.json?
Keep the key out of version control. Use the user-level configuration file, an environment variable if your client supports it, or add the project file to .gitignore. Rotate the key from the dashboard if it leaks.
Can I check a page on my local dev server?
No. Search Console only knows about public URLs Google has crawled. Use it to check production after deploys and use local tooling, such as Lighthouse, for pre-release checks.