Audit a Website's SEO and Write a Report of Fixes in Priority Order

## Split SEO Research into Specialist Checks Loaded Only When Needed Separate the system into three layers: - The directive layer defines shared principles, routing rules, evidence standards, and safety constraints. - The orchestration layer selects the smallest set of specialist workflows needed for the request. - The execution layer performs deterministic collection, analysis, validation, and report generation. Use progressive disclosure. Keep routing metadata and critical rules readily available, but load detailed methods, references, and templates only when the task needs them. Maintain distinct specialists for technical search health, content quality, structured data, images, sitemaps, performance, AI-search visibility, local discovery, backlinks, topic architecture, user experience, internationalization, commerce, and change monitoring. Do not duplicate an existing specialist workflow. Extend the current routing surface when a new capability overlaps established coverage. ## Confirm the Site and Goal, Then Pick Only the Checks Needed Before collecting data: 1. Identify the target site, page set, market, language, and business objective. 2. Detect the operating context, such as software, commerce, local service, publisher, or agency. 3. Classify the request as a full audit, page analysis, technical review, content research, structured-data review, link analysis, topic planning, local analysis, experience review, or drift comparison. 4. Select only the relevant specialists and evidence sources. 5. State assumptions, unavailable data, and any cost-bearing sources before use. For a full audit, run independent specialists in parallel when their inputs do not depend on one another. Use no more than 15 concurrent specialists, and synthesize only after every assigned result is accounted for. For a narrow question, do not expand into a full-site audit without explicit scope. Match effort and evidence depth to the decision the user needs to make. ## Use Measured Data and Keep Passwords and Keys Out of Reports Prefer primary and directly measured evidence: - search-console queries, pages, coverage, and inspection results; - field performance and historical web-vitals data; - analytics for organic traffic and conversions; - rendered pages, HTML, screenshots, sitemaps, and structured data; - backlink indexes followed by live-link verification; - marketplace, keyword, or competitor data when relevant and authorized. Validate every user-supplied URL before making a request. Reject private addresses, loopback targets, cloud metadata endpoints, unsafe redirects, and destinations that fail DNS or canonical-host checks. Never place credentials, client secrets, access tokens, or service-account material in reports, source control, prompts, or logs. Read secrets from an approved runtime location and keep client credentials separate from refresh or access tokens. Do not hardcode user-specific paths. Resolve resources relative to the running component or an approved user configuration directory. When a paid data source is optional, estimate its cost and confirm the budget before retrieval. Record which findings came from live data, cached data, inference, or unavailable sources. ## Check a Whole Site, from Search Engine Access to Backlinks After scope and access are established: 1. Establish crawl boundaries, canonical hosts, languages, and representative templates. 2. Test crawlability, indexability, redirects, canonicals, robots directives, sitemaps, status codes, and security-relevant delivery behavior. 3. Review page titles, headings, internal links, duplication, thin content, readability, expertise signals, and citation gaps. 4. Validate structured data against current eligibility and required fields. 5. Measure performance using both field data and reproducible lab observations. 6. Inspect rendered desktop and mobile experiences, including layout shifts and blocked content. 7. Evaluate image discoverability, dimensions, formats, loading behavior, and descriptive metadata. 8. Review backlinks, anchors, referring domains, spam indicators, and whether sampled links still exist. 9. Examine search-experience fit: intent, page type, user journey, conversion path, and accessibility. 10. Record every finding with evidence, affected scope, severity, and a reproducible verification method. Do not infer site-wide failure from one page. Distinguish isolated examples, template-level patterns, and domain-wide conditions. ## Add Specialist Checks, Like Local or International, Only When They Fit Add only the modules supported by the site and goal: - Local discovery: business-profile completeness, name-address-phone consistency, citations, reviews, map visibility, local schema, and competitor radius. - International search: language-region targeting, reciprocal annotations, canonical interaction, localization quality, and culturally appropriate intent. - Commerce: product and offer markup, merchant-listing requirements, marketplace visibility, category architecture, faceting, and duplicate variants. - Topic architecture: semantic clusters, intent separation, internal-link opportunities, cannibalization, and content gaps. - AI-search visibility: crawler access, extractable answers, source clarity, entity consistency, and citation-worthy passages. - Programmatic pages: template quality, unique value, index controls, data provenance, and safeguards against thin-scale generation. - Competitor comparison: factual claim verification, fair comparison criteria, differentiation, and update cadence. Specialized analysis must not lower the shared evidence standard. Label assumptions, distinguish correlation from causation, and identify data that would change the conclusion. ## Record a Starting Point and Compare Later Changes Against It Capture a reproducible baseline before material changes. Store the observation time, target set, collection method, and normalized measurements needed for later comparison. Compare later states with explicit rules. A mature drift monitor may evaluate 17 change rules across three severity levels, but each alert must still identify: - what changed; - where it changed; - whether the difference is expected; - the supporting before-and-after evidence; - the likely search or user impact; - the recommended verification or rollback action. Track performance trends over a meaningful window rather than reacting to a single sample. Separate deployment-related change, external search volatility, seasonality, and measurement noise. Do not notify indexing systems, overwrite a baseline, or apply an optimization merely because drift was detected. Preserve the previous state and obtain the authorization appropriate to the action. ## Rank Fixes by Impact and Strength of Evidence Merge specialist results into one evidence ledger. Deduplicate overlapping findings without erasing independent corroboration. Prioritize each recommendation by: 1. expected impact on discovery, traffic quality, or conversion; 2. confidence in the causal evidence; 3. affected scope and recurrence; 4. implementation cost and dependency; 5. reversibility and operational risk; 6. speed and reliability of post-change verification. Lead with the highest-value, best-supported actions. Separate critical blockers, high-impact improvements, routine maintenance, and experiments. For every recommendation, state the problem, evidence, likely cause, proposed action, owner or dependency, success metric, and validation method. If evidence is insufficient, recommend the next measurement rather than presenting a guess as a fix. ## Build the Report and Check It for Empty or Broken Sections Use a consistent report structure: 1. title and scope; 2. table of contents with section scores; 3. executive summary; 4. evidence and findings by analysis area; 5. prioritized recommendations; 6. methodology, limitations, and data provenance. Use tables for comparable findings and charts only when they clarify a material relationship. Every chart needs a caption, readable labels, and a direct connection to the surrounding analysis. When producing a printable report, use a stable page size, consistent visual hierarchy, accessible status colors, and high-resolution charts such as 200 DPI. Avoid layout rules known to create large blank gaps. Run an automated post-generation review for empty images, duplicate sections, unexpectedly thin sections, broken references, and rendering defects. Do not present the report as complete until that review passes, then summarize the final status and any remaining limitations.