The SEO Crawler MCP is a self-contained, local website crawling and SEO analysis server backed by SQLite storage. It provides four core tools:
run_seo_audit — Crawl any website (up to 10,000 pages, 10 levels deep) using Chrome or Googlebot user agents, storing page data, links, headers, and metadata in a local SQLite database.
analyze_seo — Run 25+ SQL queries across five categories, returning structured reports with affected URLs and fix recommendations in structured, summary, or detailed formats.
query_seo_data — Execute individual named queries (e.g., missing-titles, broken-internal-links, orphan-pages, missing-csp) for targeted results.
list_seo_queries — Discover all 28 predefined queries, filterable by category or priority (CRITICAL/HIGH/MEDIUM/LOW).
What gets detected:
Critical: Missing titles, broken internal links, 4xx/5xx errors
Content: Duplicate/missing titles, descriptions, H1s, thin content
Technical: Redirect chains, orphan pages, canonical mismatches, non-HTTPS pages
Security: Missing CSP/HSTS/X-Frame-Options/Referrer-Policy headers, unsafe external links
Optimisation: Title/description length issues, missing images, excessive external links
Everything runs locally with no external API dependencies. It supports both AI assistant orchestration via MCP tools and direct terminal CLI usage for large or scheduled crawls.
Provides an embedded SQLite database for storing website crawl data, allowing AI agents to perform automated SEO audits and custom SQL queries to analyze site structure, metadata, and technical issues.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SEO Crawler MCP crawl https://example.com and audit it for technical SEO issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project has been superseded by SEO Audit Console.
SEO Crawler crawled your whole site into SQLite and gave Claude 25+ analysis queries over the result. The crawler survived the move - it was rewritten to be stdio-safe and it is now the crawl half of a bigger tool.
SEO Audit Console keeps the crawl and adds the thing the crawl could never tell you on its own: what people actually searched for to get there. It merges the crawl with your Google Search Console history and on-demand DataForSEO data, then ranks every finding by the clicks it could recover rather than by severity.
A flat crawler sells you severity. This ranks by yield.
git clone https://github.com/houtini-ai/seo-audit.gitDocs and setup: github.com/houtini-ai/seo-audit
Related MCP server: seoagent
The npm package still installs. @houtini/seo-crawler-mcp is deprecated, not unpublished. Nothing you have running will break.
This repository is archived. The code stays readable and every existing link keeps working, but there are no further releases, and issues and pull requests are closed.
The crawler got better on the way over. It no longer depends on Crawlee (which logged to stdout and corrupted MCP's JSON-RPC framing), it seeds discovery from sitemaps and known GSC URLs rather than links alone, and it guards against redirects that wander off-host.
Start a crawl on the new tool and it builds its own database:
start_crawl for https://example.com/Run refresh_property instead if you want the crawl, the Search Console sync and URL inspection in one pass.
Part of the Houtini open-source MCP set. Questions: hello@houtini.com.
Analyze SEO data from a completed crawl. Runs 25+ SQL queries to detect critical issues, content problems, technical SEO issues, security vulnerabilities, and optimization opportunities. Returns structured report with affected URLs and fix recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| crawlPath | Yes | Path to crawl output directory (e.g., C:/seo-audits/example.com_2026-02-01_abc123) | |
| includeCategories | No | Optional: Filter analysis by categories. Default: all categories | |
| maxExamplesPerIssue | No | Maximum example URLs to return per issue. Default: 10 | |
| format | No | Output format: "structured" (organized format, default), "summary" (text overview), "detailed" (full JSON). Default: structured |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'runs 25+ SQL queries' and returns a 'structured report', which gives some insight into computational intensity and output format. However, it lacks critical details like execution time, resource requirements, error handling, or whether it modifies data (though 'analyze' suggests read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that efficiently convey core functionality. It's front-loaded with the main purpose, though the second sentence could be slightly more streamlined. Every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and no output schema, the description provides adequate context about what the tool does and returns. However, it lacks details about the report structure, error conditions, or performance characteristics that would help an agent use it effectively, especially given the computational intensity implied by '25+ SQL queries'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing good documentation for all parameters. The description adds marginal value by mentioning 'critical issues, content problems, technical SEO issues, security vulnerabilities, and optimization opportunities', which loosely maps to the 'includeCategories' enum values. However, it doesn't explain parameter interactions or provide usage examples beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyze SEO data', 'detect issues', 'returns structured report') and resources ('completed crawl', '25+ SQL queries'). It distinguishes from siblings by focusing on post-crawl analysis rather than listing queries, querying data, or running audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('from a completed crawl') but doesn't explicitly state when to use this tool versus alternatives like 'run_seo_audit' or 'query_seo_data'. No exclusions or prerequisites are mentioned, leaving the agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available SEO analysis queries with descriptions, priorities, and fix recommendations. Optionally filter by category or priority level.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional: Filter by category | |
| priority | No | Optional: Filter by priority level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read-only listing operation but doesn't mention critical behaviors such as whether results are paginated, if there are rate limits, authentication requirements, or what the output format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and included data, the second adds optional filtering. Every word contributes to understanding, with no redundant or vague language, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return values (e.g., format of 'descriptions, priorities, and fix recommendations'), potential limitations, or error handling. For a tool that lists data with multiple attributes, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema (including enums and descriptions). The description adds marginal value by mentioning filtering options but doesn't provide additional semantic context beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available SEO analysis queries with descriptions, priorities, and fix recommendations.' It specifies the verb ('List') and resource ('SEO analysis queries') with details about what information is included. However, it doesn't explicitly differentiate this from sibling tools like 'query_seo_data' or 'analyze_seo', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning optional filtering by category or priority level, suggesting when to use these parameters. However, it lacks explicit guidance on when to choose this tool over alternatives like 'analyze_seo' or 'run_seo_audit', and doesn't specify prerequisites or exclusions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a specific SEO analysis query by name. Use list_seo_queries to see available queries. Returns detailed results with affected URLs and context.
| Name | Required | Description | Default |
|---|---|---|---|
| crawlPath | Yes | Path to crawl output directory | |
| query | Yes | Query name (e.g., "missing-titles", "duplicate-h1", "orphan-pages"). Use list_seo_queries to see all available queries. | |
| limit | No | Optional: Maximum number of results to return. Default: 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool 'Returns detailed results with affected URLs and context', which gives some behavioral insight about output format. However, it doesn't mention important traits like whether this is a read-only operation, potential performance/rate limits, authentication needs, or what 'execute' entails computationally. The description adds basic context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: first states the core purpose, second provides prerequisite guidance, third describes return format. No wasted words, front-loaded with the main action. Excellent structure for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers purpose, prerequisite, and return format at a high level, but doesn't address behavioral aspects like safety, performance, or error handling. For a query execution tool with no output schema, more detail about result structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it reinforces that 'query' should be a name and mentions list_seo_queries for discovery (which is also in the schema). It doesn't provide additional semantic context about how parameters interact or usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a specific SEO analysis query by name' with the resource being 'SEO analysis query'. It distinguishes from siblings by mentioning list_seo_queries for discovery, but doesn't explicitly differentiate from analyze_seo or run_seo_audit. The verb 'execute' is specific, though not as precise as it could be regarding what execution entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use list_seo_queries to see available queries' establishes a prerequisite. It implies usage for executing named queries rather than other SEO operations, but doesn't explicitly state when NOT to use it or name alternatives among siblings like analyze_seo or run_seo_audit, which could cause confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl a website and extract comprehensive SEO data using Crawlee HttpCrawler. Returns crawl ID and output path.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL to crawl (must include http:// or https://) | |
| maxPages | No | Maximum number of pages to crawl (1-10000). Default: 1000 | |
| depth | No | Maximum crawl depth (1-10). Default: 3 | |
| userAgent | No | User agent to identify as: "chrome" (default, Chrome browser) or "googlebot" (Googlebot crawler). Default: chrome |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns a crawl ID and output path, which adds some context, but fails to cover critical aspects such as whether this is a long-running operation, potential rate limits, authentication needs, or what 'comprehensive SEO data' entails. The use of 'Crawlee HttpCrawler' hints at technical implementation but doesn't clarify behavioral traits for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, consisting of two sentences that efficiently convey the core functionality and return values without unnecessary details. Every sentence earns its place by stating the action and output, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a crawling tool with 4 parameters and no output schema, the description is moderately complete. It specifies the action and return values but lacks details on output format, error handling, or operational constraints. Without annotations, it should do more to guide the agent on usage and behavior, but it meets a minimum viable level for understanding the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or providing usage examples. The baseline score of 3 reflects adequate coverage by the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Crawl a website and extract comprehensive SEO data') and resource ('website'), specifying the tool's purpose. It distinguishes from siblings by mentioning the crawling aspect, though it doesn't explicitly contrast with tools like 'analyze_seo' or 'list_seo_queries'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'analyze_seo' or 'list_seo_queries'. The description implies usage for crawling and extracting SEO data but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.1.3analyze_seolist_seo_queriesquery_seo_datarun_seo_auditScored across 4 tools
The tools have mostly distinct purposes, but there is some overlap between analyze_seo and query_seo_data, as both involve executing SEO analysis queries. However, analyze_seo runs a predefined set of queries, while query_seo_data allows for executing specific queries by name, which helps differentiate them. The other tools (list_seo_queries and run_seo_audit) are clearly distinct.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., analyze_seo, list_seo_queries, query_seo_data, run_seo_audit). The naming is predictable and readable, with no deviations in style or convention.
With 4 tools, the count is reasonable for an SEO crawler server, covering key operations like crawling, listing queries, executing queries, and analyzing data. It might be slightly thin for a comprehensive SEO toolset, but it is well-scoped and each tool earns its place.
The toolset covers core SEO analysis workflows, including crawling, query listing, and data analysis. However, there are notable gaps, such as missing update or delete operations for managing queries or crawl data, and no tools for monitoring or reporting beyond the initial analysis. This could limit agent flexibility in handling ongoing SEO tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.
Query your SEO data in plain language: rankings, audits, backlinks, competitors and AI visibility.
Technical SEO + GEO (AI-search) site audits: hosted crawls, prioritized fixes, report diffs.
