---
name: seo-site-audit
description: Audit a public website or selected pages for technical SEO problems and produce a prioritized fix list. Use when the user needs an SEO audit, indexability review, page health check, or evidence-based developer tickets using Toolmu DataForSEO.
---

# Technical SEO audit

## Before you start

Read [the shared research contract](../connect-toolmu/references/research-data.md) and [marketplace usage](../connect-toolmu/references/marketplace-usage.md). Use the existing Toolmu connection. The agent performs analysis; Toolmu supplies the evidence.

## Inputs

A public website or specific page URLs, the affected search market, and whether the problem affects one page or a group of pages.

Ask only for information that changes the task. Accept ordinary links and names; resolve technical identifiers from verified results. Confirm missing market or scope before dependent paid calls.

## Tool selection

Inspect the current contract with Toolmu `get_tool`, then call `execute_tool` only for the steps that need data:

- `onpage-instant-page-audit-dataforseo`
- `onpage-content-parsing-dataforseo`
- `onpage-lighthouse-page-audit-dataforseo`
- `onpage-task-post-dataforseo`
- `onpage-non-indexable-dataforseo`
- `onpage-redirect-chains-dataforseo`
- `onpage-links-dataforseo`

The catalog's current input and credit ceiling override examples in this document. Do not fabricate parameters, silently use a different supplier, or treat a search snippet as full source content.

## Workflow

1. Start with the supplied URL and one representative page per important template, at most three pages. Record response status, robots/indexability signals, canonical, title, headings, links, and accessible content.

2. Use Instant Page for page findings. Read actual failed checks and their underlying values; do not turn every provider flag into a critical issue.

3. Run Lighthouse only when performance or accessibility is in scope. Distinguish laboratory measurements from real-user Core Web Vitals.

4. Use a crawl only when site-wide evidence is needed and the live Tool contract exposes the required bound. The current task-post contract may fix ten pages. Explain this scope, submit once, and use the existing run/poll result rather than submitting another crawl.

5. Use downstream crawl tools only with a verified supplier task ID from that same crawl, and only when the catalog contains the required tool. Never invent summary/pages endpoints or IDs.

6. Group repeated issues by page template and likely cause. For each fix, show an affected URL, observed value, expected behavior, suggested change, and how to verify it.

7. Order blocking access/indexing issues before canonical/redirect problems, then content structure and performance. Mark uncertain findings for manual verification.

## Deliver

An audit scope statement, a prioritized issue table, and developer-ready tickets with URL evidence, impact, fix, and verification steps. List pages checked and pages not checked. Deliver findings in the agent's normal output.

Include source links, actual market/date, returned sample size, missing coverage, run IDs, and confirmed credits. Let the user's agent choose the presentation; do not invoke an MCP App or a render tool.

## Boundaries

A three-page sample or ten-page crawl is not a full-site audit. Do not change the site, claim Search Console access, or claim a live field-performance pass from Lighthouse.

## Example request

> Audit [website URL] and give our developer the first [three] SEO fixes with evidence.