Turn a site-wide speed crawl into developer tickets by template
Crawls the whole site, pulls the full URL list for every speed-related issue, groups pages by template, audits sample URLs per template with resource-level detail, and delivers a sorted developer ticket list with honest page counts.
When to use it
When your whole site has speed or layout-shift problems and you need to hand developers a clear, prioritised list of what to fix.
What you get
A developer ticket list grouped by page template, with affected page counts, example URLs, the files involved, recommended fixes and effort, sorted by impact.
Does it change anything in my account?
No. The assistant only reads your data and reports back.
Works with
SEO Intelligence
Fill in before sending
[domain][max pages]
First, check my SEO add-on history for a crawl of [domain] that can still be reused for free. If one exists, reuse it. If not, remind me that a site-wide crawl uses SEO add-on credits and wait for my go-ahead before you start a crawl of up to [max pages] pages. The crawl runs in the background: start it, then check back with the task id every minute or two until the summary is ready.
From the crawl summary, take every issue type that relates to speed or layout stability, if it appears in the data. Examples: large page size, slow load time, redirect chains, render-blocking resources, oversized images, images without width/height. Use the issue names exactly as the summary returns them. For each of these issues, pull the full URL list (page through it), not just the first 5 examples.
Group the affected URLs by template or path pattern, for example /blog/, /product/, /category/ and landing pages. For each template, count the affected pages per issue from those full lists.
Then pick the worst URL in each template. Before running technical audits, tell me how many you plan to run (they also use add-on credits) and wait for my OK. On each worst URL, run a technical audit and a mobile Core Web Vitals check with the resource lists switched on. Use the resource lists to name the actual files: which stylesheets and scripts block rendering, how many bytes of unused CSS and JS, which images are oversized or not in a modern format, the total request count and the LCP element.
To see whether an audit finding is template-wide or a one-off, run the free mobile Core Web Vitals check (with resource lists) on 2 more URLs from the same template.
Counting rule: only issues that come from the crawl's URL lists get a page count. For issues found only in the audits, write "confirmed on X of 3 sampled URLs" instead of a page count. Do not extrapolate a page count from one URL.
Deliver a ticket list with these columns: template, issue, affected pages (or sample ratio), example URL, files or elements involved, recommended fix, effort (S/M/L), metric it should improve (LCP, CLS, INP/TBT, page weight). Sort by affected pages × severity; for sample-only issues use the sample ratio and mark them as such.
This is read-only. Do not change anything on the site.
Finds page-one pages that get impressions but few clicks, compares them to your site-wide CTR, and rewrites their meta title and description around the queries that actually bring them traffic.
When to use itWhen your pages rank on page one and get impressions but few clicks, so your titles and descriptions are probably not convincing.
Matches GA4 landing-page performance against your WordPress menus, flags valuable pages missing from the navbar, dead weight and broken links, and proposes a leaner main menu.
When to use itWhen your site menu feels cluttered or outdated and you suspect it does not point visitors to the pages that actually bring conversions.
A plugin-by-plugin action list that flags outdated, duplicate and conflicting plugins and double-firing tags.
When to use itWhen your WordPress site has too many plugins, updates piling up, or you fear duplicate tags are inflating the conversions your ads optimize toward.