Skip to main content
Glama
Panda Web Security Tools

Panda Web Security Tools

AI Search & SEO Audit: GEO, llms.txt & Schema Checker

ai_search_seo_audit
Read-only

Audit web pages for on-page SEO and AI-search readiness, including titles, meta, schema, AI crawler blocking, and llms.txt, then return scores and ranked fixes.

Instructions

Audit web pages for classic SEO and for AI-search readiness (ChatGPT, Perplexity, Claude, Google AI Overviews): titles, meta, schema/FAQ markup, author/date signals, blocked AI crawlers, llms.txt and ranked fixes, with an SEO score and an AI-readiness score per page. Unlike website_change_monitor (diffs pages over time) and hidden_ai_instructions_scanner (finds concealed prompt-injection text), this grades how discoverable and citable a page is. Use when you need an on-page SEO/GEO audit or an llms.txt draft. Do not use for change tracking (use website_change_monitor) or security scanning (use hidden_ai_instructions_scanner or email_domain_security_checker). Parameters: crawlInternalLinks multiplies pages: each URL can add up to that many same-site pages, and every page is billed, so maxPages/run_max_items is the real cost cap. generateLlmsTxt drafts one llms.txt per site lacking it at no extra charge. Pages that block our crawler are returned unbilled. Returns per item: agentSummary, url, seoScore, aiReadinessScore, title, metaDescription, h1, wordCount, schemaTypes, faqSchema, aiSearchBotsBlocked, aiTrainingBotsBlocked, llmsTxt, sitemapFound, canonical, noindex, crawlerBlocked, fixes.

Behavior: read-only; runs the Apify Actor pandadad0214/ai-search-seo-audit (https://apify.com/pandadad0214/ai-search-seo-audit) on your own Apify account. Price: $0.004 per page audited. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxPages when you leave it unset, so it also limits what is billed; setting maxPages higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

Input Schema

NameRequiredDescriptionDefault
urlsNoPage URLs. Pages to audit, one per line. https:// is added if missing (example.com/pricing works). Leave empty for a 2-page demo.
maxPagesNoMaximum pages. You pay per audited page, so this also caps the cost. Whole number, 1 to 2,000; default 50.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
generateLlmsTxtNoDraft an llms.txt for sites without one. On by default: for each site with no /llms.txt, writes a ready-to-edit draft (from the audited pages and homepage links) into the LLMS_TXT_DRAFTS record and the Sites sheet. No extra charge.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
crawlInternalLinksNoAlso audit internal pages (per URL). 0 = audit only the URLs above. 1 to 100 = also audit up to this many same-site pages linked from each URL (good for a quick whole-site check from the homepage).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/open-world semantics, while the description adds the operationally decisive facts: per-page pricing at $0.004, spending caps via run_max_charge_usd, unbilled crawler-blocked pages, typical 5-15s runtime with a 300s ceiling, and the runtime backend. That is substantial context an agent cannot get from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then differentiation, then parameters, then return shape — a sensible order, and nearly every sentence carries information. It is on the long side, and the parameter section partially restates schema text rather than only adding the multiplier/cap interactions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates every returned field plus the JSON envelope, and it covers cost, timeouts, and billing edge cases. An agent has everything needed to invoke it and interpret the result without further probing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new semantics: crawlInternalLinks multiplies billed pages, run_max_items fills maxPages when unset, and raising maxPages can bill more than is returned. These interaction effects are not derivable from the individual schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Audit web pages for classic SEO and for AI-search readiness') and enumerates the concrete checks (titles, meta, schema/FAQ markup, llms.txt, crawler blocking) so the agent knows exactly what the output grades. It also explicitly distinguishes itself from both siblings by naming what each of them does instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit positive trigger ('Use when you need an on-page SEO/GEO audit or an llms.txt draft') and explicit exclusions with named alternatives for change tracking and security scanning. Nothing about routing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.