Most on-page SEO checklists are written for marketers and die in translation. “Optimize your meta tags” isn’t a ticket a developer can close — it has no acceptance criteria, no definition of done, and no owner. Then the marketing manager wonders why the audit findings from March are still open in September.
This checklist fixes the translation problem. Every item is written the way dev teams actually work: a verifiable condition that is either true or false in production. Drop it into your sprint board as-is, assign owners, and ship. It covers the on-page layer — what lives in your code and templates. It assumes strategy (keyword mapping, content planning) is handled upstream, which is the division of labor inside a full SEO services in Pakistan program: strategists decide what each page targets; this checklist governs how the build expresses it. [Download the checklist as a formatted PDF/Sheet at the end of this guide] — printable version for sprint planning, spreadsheet version with owner/status columns for tracking.
Table of Contents
Section 1: The HTML Head (8 checks)
- ☐ One unique <title> per page, 50–60 characters, primary keyword in the first half, brand suffixed. Verify at scale: crawl with Screaming Frog, sort by duplicates — any template generating identical titles fails this check
- ☐ One meta description per page, 140–160 characters, written for click-through, unique sitewide. Missing is acceptable on deep pages (Google rewrites anyway); duplicated is not
- ☐ Exactly one rel=”canonical” per page, absolute URL, self-referencing by default. The classic bug: canonical pointing at the staging domain or at a parameterized URL — this single line has deindexed entire Pakistani ecommerce catalogs
- ☐ meta name=”robots” audit: no accidental noindex in production templates (the #1 post-launch traffic-death cause — check every template after every major release), deliberate noindex on search results, filters, cart, thank-you, and ad landing pages
- ☐ Viewport meta present (width=device-width, initial-scale=1) — mobile-first indexing means the mobile render is the page
- ☐ lang attribute correct on <html> (en, ur where applicable); hreflang set only if multi-region, reciprocal and validated
- ☐ Open Graph + Twitter card tags with a real branded image per template — this controls how pages render when shared on WhatsApp, where Pakistani B2C traffic actually circulates
- ☐ Favicon and Web App Manifest present — minor, but favicons render in mobile SERPs now
Section 2: Document Structure & Content Markup (7 checks)
- ☐ Exactly one <h1> per page, containing the page’s primary keyword, rendered as text (not an image, not injected post-load)
- ☐ Logical heading cascade — H2s section the page, H3s nest under H2s, no levels skipped, no headings used purely for font styling (that’s CSS’s job; misused headings are the most common structural defect in Elementor/page-builder sites)
- ☐ Semantic HTML5 landmarks: <main>, <nav>, <header>, <footer>, <article> where appropriate — machines chunk pages by these
- ☐ All images: descriptive alt text (empty alt=”” only for decorative), no filename-garbage alts (IMG_2041.jpg descriptions fail review), file names human-readable pre-upload
- ☐ Internal links are real <a href> anchors with descriptive anchor text — not onclick handlers, not buttons doing navigation, not “click here.” Crawlers follow hrefs; JS-only navigation orphans pages
- ☐ No text content locked inside images — headings, prices, and offers as actual text
- ☐ Tables for tabular data use <table> with header rows — structured comparisons are extraction targets for AI answer surfaces, but only if they’re parseable
Section 3: Performance & Core Web Vitals (8 checks)
Pakistani mobile networks are your real test environment. Budgets, not vibes:
- ☐ LCP ≤ 2.5s on mobile (field data in Search Console’s CWV report, not just lab) — hero images compressed, preloaded, and sized
- ☐ CLS ≤ 0.1 — explicit width/height on all images/embeds, no layout-shifting ad or banner injection
- ☐ INP ≤ 200ms — main-thread work audited; heavy page-builder and app scripts deferred or removed
- ☐ All raster images served as WebP/AVIF with responsive srcset; hero images excluded from lazy-load, below-fold images lazy-loaded (loading=”lazy”)
- ☐ JS/CSS budget enforced: unused libraries stripped, render-blocking resources minimized, third-party scripts (chat widgets, pixels) loaded after interaction or via facade — audit quarterly, they accrete like plaque
- ☐ Fonts: font-display: swap, WOFF2, subsets only — no 400KB font payloads for two weights
- ☐ Compression (Brotli/gzip) and caching headers verified on HTML and static assets
- ☐ Mobile render check on a real mid-range Android over 3G/4G throttling — if the team only tests on office WiFi and iPhones, you don’t know what your customers see
Section 4: Indexation & Crawl Plumbing (7 checks)
- ☐ robots.txt reviewed and version-controlled: blocks admin/cart/internal search, does not block CSS/JS/assets, sitemap referenced; AI crawler directives (GPTBot, PerplexityBot, ClaudeBot) set as a deliberate decision, not an accident
- ☐ XML sitemap auto-generated, submitted, and clean — only 200-status, indexable, canonical URLs; no redirects, no noindexed pages, split by type at scale (products/categories/posts)
- ☐ One canonical host + protocol: all variants (http/https, www/non-www, trailing-slash) 301 to a single form, verified with curl, redirect chains ≤ 1 hop
- ☐ Custom 404 returning actual 404 status (not 200 — “soft 404s” pollute the index), with navigation back to money pages
- ☐ Redirect map maintained as a repo file — every removed/renamed URL gets a 301 to its closest equivalent in the same release; deleted-without-redirect pages are equity thrown in the bin
- ☐ Parameter/facet URLs controlled — filters and sorts noindexed or canonicalized to the base category; verify by site: searching your domain for ? URLs (the index-bloat pattern behind the 3,900-vs-1,200 case in this series’ Hub 1 case study)
- ☐ Pagination crawlable: real linked page URLs (/category/page/2/) behind any infinite-scroll implementation
Section 5: Structured Data (5 checks)
- ☐ JSON-LD only, templated, pulling live variables — never hand-coded static prices that go stale
- ☐ Organization + WebSite + BreadcrumbList sitewide; Article (with real author Person and dateModified) on content; Product/Offer with priceCurrency on ecommerce; LocalBusiness per location page; FAQPage where FAQs visibly exist
- ☐ One source of truth per schema type — theme, plugin, and page-builder each emitting their own conflicting Organization block is the standard WordPress failure; consolidate
- ☐ Everything validates in the Rich Results Test / Schema Validator, and marked-up content is visible on the page (invisible markup is a guidelines violation)
- ☐ Search Console Enhancements monitored post-release — schema breaks silently on theme updates; someone owns the alert
Section 6: Template-Level & Release Discipline (5 checks)
- ☐ Per-template SEO spec exists (title pattern, H1 source, schema types, canonical logic for product/category/post/location templates) — so every new page inherits correctness instead of needing retro-audits
- ☐ Staging is noindexed AND auth-gated; production is not — checked both directions in the deploy checklist, every release (each direction of this failure is a classic)
- ☐ SEO smoke test in CI/CD: post-deploy automated check of title/canonical/robots/status on 10 representative URLs — five minutes of automation that catches the catastrophic template regressions
- ☐ URL rules enforced: lowercase, hyphens, no session parameters, human-readable slugs, structure stable (URL changes require the redirect map, check 28)
- ☐ Quarterly full crawl (Screaming Frog or equivalent) diffed against the previous quarter — new duplicate titles, broken links, orphan pages, and status-code drift surfaced as tickets, not surprises
How to Run This With Your Team
First pass: run all 40 as an audit sprint — most sites fail 12–20 on first contact, and Sections 1, 3, and 4 typically hide the traffic-killers. Then: items 36–40 convert the checklist from a one-time cleanup into a permanent quality gate, which is the actual goal — on-page SEO as a property of your build process, not a recurring rescue project.
Get the downloadable versions here: (printable PDF for sprint planning + Google Sheet with owner/status/priority columns) — and if the audit surfaces more red than your team has bandwidth for, this exact checklist is the execution layer of our technical and on-page SEO services: we run the audit, hand your developers the prioritized tickets, and verify the fixes in production. Next in this cluster: what your agency’s monthly report should contain — including how to check they actually fixed any of this.
GET IN TOUCH
Get 1 Free Consultation Call
FAQ
How is this different from a normal SEO checklist?
Every item is a verifiable production condition with a testing method — written as acceptance criteria for developers, not advice for marketers. It’s designed to be pasted into Jira/Trello/Linear, not read and forgotten.
Which checks matter most if we can only do a few?
The traffic-killers: robots/noindex audit (4, 24), canonical correctness (3, 26), sitemap hygiene (25), Core Web Vitals on mobile (16–18), and the staging/production check (37). These are the items whose failure costs entire sites, not percentages.
How often should the full checklist run?
Full pass at launch and after any replatform/redesign; the CI smoke test (38) every deploy; the crawl diff (40) quarterly. Continuous small checks beat annual heroics.
Does this checklist cover content SEO?
Deliberately not — keyword strategy, content depth, and internal-link architecture are the strategist’s layer. This governs everything the code controls, so content lands on templates that don’t sabotage it.
