What this prompt does
This prompt runs a structured technical SEO audit and returns prioritized, concrete fixes rather than a generic checklist. It frames the model as a senior technical SEO engineer auditing a specific live site and asks for six areas: indexation and crawl, international and structured-data checks, Core Web Vitals, internal linking and error handling, thin and duplicate content, and a prioritized fix table. The explicit instruction to avoid "generic advice" pushes the output toward findings tied to the site's actual stack.
The four variables make the audit relevant. [url] is the site under audit. [platform] tells the model which stack-specific issues to watch for, so advice fits a Laravel app or a WordPress site differently. [known_concern] directs extra scrutiny at the problem you already suspect, like duplicate tag pages. [primary_kpi] is what every recommendation ties back to, and it drives the impact ranking in the final table. That impact-times-effort sort is the difference between a usable audit and a 90-item list nobody touches. Anchoring each finding to a single KPI also makes the report easy to defend when a stakeholder asks why a fix is worth the engineering time.
When to use it
- Indexation dropped and you need to triage canonicals, robots, and noindex fast
- You're inheriting a site and want a structured map of its technical debt
- You suspect a specific issue (
[known_concern]) and want it investigated in context - You need Core Web Vitals findings with likely causes, not just scores
- You want fixes ranked by impact and effort so you know what to do first
- You're reporting to stakeholders and need a top-5 fix-first list
Example output
You get a findings table covering indexation, hreflang and schema validity, Core Web Vitals (LCP, INP, CLS) with a probable cause behind each weak metric, internal linking and HTTPS/redirect/error checks, and thin or duplicate content flags. The table is ranked by impact times effort, with each row tied to the primary KPI, followed by a top-5 "fix first" list so you have an immediate action plan.
Pro tips
- Do the prioritization step ruthlessly; an impact-times-effort sort against
[primary_kpi]is what makes the audit usable - Set
[known_concern]to the issue you actually suspect so the model spends scrutiny where it counts (e.g. duplicate tag and category pages) - Give an accurate
[platform]so stack-specific fixes apply — server-rendered Laravel and a JS SPA need different crawl advice - The model cannot crawl the live site, so feed it real data (Search Console exports, PageSpeed results, sample URLs) for grounded findings
- Tie
[primary_kpi]to something measurable like indexed pages and clicks, so you can verify the fixes worked later - Treat Core Web Vitals causes as hypotheses to confirm in the field, not measured numbers
