TL;DR
Generic 100-point SEO checklists waste your time: half the items do not apply to your stack, the other half are too vague to verify. Instead, feed a codebase-aware AI (Claude Code, Cursor, or Codex) a precise description of your stack and have it generate a 30-60 item checklist grouped into six sections, each item labeled P0/P1/P2 and paired with a verification command you can actually run. Prune the inapplicable items by hand, commit it as SEO_CHECKLIST.md, and regenerate quarterly. Budget about 20 minutes for the first pass. Anchor every threshold to current numbers: as of June 2026, the Core Web Vitals targets are LCP under 2.5s, INP under 200ms, and CLS under 0.1, measured at the 75th percentile of real-user data.
Why a generic checklist fails you
The pain is concrete. You grab a 100-item technical SEO checklist off a blog. A third of it is dead weight for your stack: AMP configuration, jQuery deferral, Magento layered navigation, none of which you run. Another third is so vaguely worded (“optimize crawl budget”, “improve site structure”) that you cannot tell whether you have already done it. What is left is a handful of genuinely useful items buried in noise, and no way to prove any of them are still true six months from now.
A stack-specific checklist with a verification command per item fixes both problems. It is also the artifact a contractor actually uses. Hand someone a generic PDF and it sits unread; hand them curl -I https://example.com/sitemap.xml next to “sitemap returns 200 and correct content-type” and they run it.
Who this is for
- Indie devs running a content site who need a baseline without hiring an agency.
- Small SEO teams supporting a single product, where one stack-aware list beats a shared template.
- ICs onboarding to a new project who must assess the SEO baseline before they can fix anything.
- Anyone handing a site to a contractor — the checklist plus verification commands is the deliverable that survives the handoff.
When to reach for it
Run this before a launch, after a stack migration (Next 13 to 15, WordPress to Astro, anything that touches routing or rendering), when onboarding a new SEO contractor, or after a traffic dip where you cannot tell whether the cause is technical or content. Also refresh it when Google ships a documented change — for example, the INP metric replacing FID, or a structured-data guideline update — so the checklist captures what changed instead of quietly missing it.
Pick the right AI tool
This task rewards a model that can read your actual repository, not just answer from a chat box. As of June 2026:
| Tool | Best for | Models available | Price (June 2026) |
|---|---|---|---|
| Claude Code | Reading the whole repo, generating + verifying across many files | Claude Opus 4.7, Sonnet 4.6 (Anthropic only) | Bundled in Claude Pro $20/mo; Max $100/$200 |
| Cursor | Inline edits while you review each item in the editor | Sonnet 4.6, Opus 4.7, GPT-5.5, Gemini 3.1 Pro, Composer 2.5 | Pro $20/mo (~$16 annual) |
| Codex | Terminal-driven runs, scriptable checklist regeneration | GPT-5.5 | Included with ChatGPT Plus $20/mo |
| ChatGPT / Gemini chat | Quick draft if you paste the stack description manually | GPT-5.5 / Gemini 3.1 Pro | Plus $20 / Google AI Pro $19.99 |
For a checklist tied to your codebase, prefer a tool that can open the repo. Claude Code reads and reasons across the whole project, which is why it generates fewer inapplicable items — it can see that your pages are static rather than guessing. If you live in an editor, Cursor’s Sonnet 4.6 covers the same ground with you reviewing each line. Either way, use a frontier model (Opus 4.7 or Sonnet 4.6); a smaller model invents more verification commands that do not exist.
For deeper code-aware audits, see the Claude Code SEO audit tutorial.
Step by step
- Describe your stack in one paragraph. Include framework + version, hosting provider, render mode (SSR / SSG / ISR / hybrid), CDN, image strategy, sitemap source, and i18n approach. The more specific the description, the fewer wrong items you delete later.
- Ask for six sections. Have AI group the checklist into crawl, render, performance, schema, internationalization, and monitoring. Six is the right number: fewer sections drop categories, more produce overlap.
- Force an explicit priority rubric. Each item is P0 (blocks launch or fixes a live regression), P1 (within 30 days), or P2 (nice to have). Spell the rubric out in the prompt so the model applies it consistently.
- Demand a verification command per item. A
curl, aview-sourcesearch, a Lighthouse target, or a Search Console report. Examples:curl -I https://example.com/sitemap.xml,view-sourcesearched forrel="canonical", Lighthouse Performance score over 90, INP under 200ms in the Core Web Vitals report. - Prune against your real stack. Walk every P0 item and ask: does this apply to my setup? Astro SSG does not need ISR cache headers; an SSR Next route does. Delete the items that do not fit.
- Save and commit. Store it as
SEO_CHECKLIST.mdwith the date and a one-line stack snapshot. Future you needs to know which version of the stack the checklist was written for. - Regenerate quarterly. Search Console signals shift, your framework ships new features, and schema vocabularies evolve.
A copy-ready prompt
Paste this into Claude Code, Cursor, or Codex with the repo open, replacing the bracketed parts:
You are a technical SEO engineer. Read this repository and generate a
technical SEO checklist tailored to its actual stack — do not include
items that do not apply to what you see in the code.
Stack: [Astro 5 SSG, Firebase Hosting, @astrojs/sitemap, content
collections for EN/ZH, no client-side router].
Output a markdown checklist grouped into exactly six sections:
1. Crawl 2. Render 3. Performance 4. Schema 5. Internationalization 6. Monitoring
For every item:
- Label it P0 (blocks launch / fixes a live regression), P1 (within 30
days), or P2 (nice to have). Apply this rubric strictly.
- Add one verification command, URL pattern, or measurable target I can
run myself (curl, view-source search, Lighthouse metric, or a specific
Search Console report). Do not invent flags; only use commands that
actually exist.
- Cite the file or route in the repo it applies to where you can.
Keep it to 30-60 items after removing anything inapplicable.The instruction to cite a file or route is what keeps the model honest — if it cannot point at where an item applies, that item is usually a hallucination you can cut.
What good output looks like
A trimmed example of three items for an Astro SSG content site:
| Section | Item | Priority | Verify |
|---|---|---|---|
| Crawl | robots.txt allows Googlebot and links the sitemap | P0 | curl https://example.com/robots.txt shows Sitemap: line |
| Render | Each article emits a self-referencing rel="canonical" | P0 | view-source of an article, search rel="canonical" |
| Performance | LCP under 2.5s on the highest-traffic article | P1 | Search Console Core Web Vitals report, 75th percentile |
Notice every row names a concrete file or page and a command. If your AI output has rows that read “improve crawlability” with no verify column, send it back.
Stack-specific items to expect
Astro (SSG): hydration boundaries (avoid client:load on above-fold static blocks), @astrojs/sitemap integration, reciprocal hreflang across language collections, lastmod only updated on real content changes. Pair the sitemap line with the Codex sitemap review tutorial.
Next.js: render mode per route (SSG vs SSR vs ISR), the Metadata API and generateMetadata, a dynamic OG image route via next/og (opengraph-image.js), middleware redirects, and an explicit ISR revalidation policy. The dynamic OG route is App Router only, so flag it as N/A on a Pages Router project.
WordPress: list your active plugins in the stack description and AI folds in plugin-specific items — Yoast vs RankMath canonical conflicts, duplicate Article/FAQ schema emitted by two plugins at once, and any caching plugin that strips Vary headers.
Hugo: the sitemap.xml template, canonifyURLs behavior, and outputs config for any AMP or RSS variants you actually ship.
Quality gate before you commit
- Every item has a verification command, URL, or measurable target. If it cannot be verified, it cannot be claimed done.
- Every P0 item is something you can fix in your own codebase. Hosting-provider items (TTFB from the CDN, edge cache rules) go in their own section.
- No item references a feature absent from your framework version. “Use the Next.js dynamic OG image route” only applies to App Router (Next 13+).
- No duplicate items across sections. AI loves to repeat canonical-tag checks in both crawl and render — keep one.
- The full pass runs in under 60 minutes for someone who knows the stack. If it takes longer, split into a P0-only quick check and a P1+P2 deep audit.
First-run exercise
Run this on a single page first, not the whole site. Pick the homepage or your highest-traffic article. Generate the checklist, then verify every P0 item against that one page. In practice the model produces a handful of items that do not apply (it assumed SSR on an SSG page) and a few verification commands that query a property that does not exist. Mark these in the checklist file so the next quarterly refresh does not repeat them, refine your stack description with what you learned, and regenerate.
Common mistakes
- Starting from a generic checklist instead of generating one for your stack. You spend more time deleting than verifying.
- Skipping the verification command field. Without it, items rot and nobody can prove they are still done.
- Treating the checklist as permanent. Google and frameworks ship changes; a 12-month-old list quietly misses real issues.
- One giant checklist for multiple sites. Stack differences make this worse than per-site lists. A staging site (noindex) has different rules than production.
- Letting AI invent commands. Models confidently produce flags like
curl --google-botthat do not exist. Run every command before you trust it. - Putting content tasks in a technical checklist. “Update the CMS” or “improve content” belong elsewhere; this list is technical SEO.
FAQ
- How many items should it have? 30 to 60 after pruning, versus the 80 to 150 in generic templates. A much larger list usually means duplication or scope creep into content SEO.
- What are the current Core Web Vitals thresholds? As of June 2026, LCP under 2.5s, INP under 200ms, and CLS under 0.1, all measured at the 75th percentile of field data in Search Console. INP is the most commonly failed of the three, so prioritize it on interactive pages.
- Which AI tool should I use? A codebase-aware one. Claude Code reads the whole repo and produces fewer inapplicable items; Cursor is better if you want to review each item in the editor. Both run frontier models (Opus 4.7 / Sonnet 4.6) that hallucinate fewer commands than smaller models.
- Can AI run the checklist for me? It can draft and help verify, but the verification command is what you actually run. Do not trust the model’s self-report that an item passes — confirm it with the command.
- Does this work for SaaS landing pages, not just content sites? Yes. The six categories stay the same; the P0 items shift toward render mode and Product/Organization structured data.
- How is structured data different in 2026? Structured data is still not a direct ranking factor, but valid schema feeds rich results and AI Overview citations. The schema types worth checking are Organization, Article/BlogPosting, FAQPage, Product, and LocalBusiness — validate each in the Rich Results Test.