Author: admin

An SEO audit checklist does not replace a full report — but it stops the chaos of «we looked at everything a little» and ended up with twenty unprioritized tickets. If you are a developer, tech lead, or PM with front-end ownership, this list gives you a clear path: from blockers that stop indexing to fine-tuning CTR and rich results.

Order matters. First confirm Google can index; then fix URLs, technical on-page, speed, and links. For narrative context on each block, pair this with our technical SEO audit step by step; here the focus is execution and checkboxes.

Table of contents

• Before you start: URLs and tools
• Phase 1 — Indexing and crawling
• Phase 2 — Architecture and URLs
• Phase 3 — Technical on-page
• Phase 4 — Performance and Core Web Vitals
• Phase 5 — Internal links and structured data
• How to score and prioritize findings
• Mistakes that invalidate the audit
• FAQ

Before you start: URLs and tools

Do not audit «the whole site» in the abstract. Pick a representative sample — 8–15 URLs is usually enough:

• Home and 2–3 service or product landings.
• 1–2 blog posts with organic traffic (Search Console).
• 1 category or listing template if applicable.
• 1 URL you already suspect is broken (404, slow, duplicate).

Minimum tools (free):

• Google Search Console — indexing, sitemap, field CWV.
• PageSpeed Insights — lab + field data per URL.
• Rich Results Test — schema and SERP eligibility.
• Browser DevTools — network, console, View Source.
• Desktop crawler (Screaming Frog, Sitebulb, etc.) — optional but very useful on sites >50 URLs.

If you are unsure what to measure before opening tickets, review SEO for developers: what to measure first and our SEO DevTools guide.

Phase 1 — Indexing and crawling

If Google does not index, nothing else competes. Check each item; any ❌ here is critical priority.

• ☐ Correct Search Console property (domain or URL prefix matching production).
• ☐ robots.txt does not block indexable sections (blog, landings, product pages).
• ☐ Key URLs free of accidental noindex (meta robots or HTTP header).
• ☐ XML sitemap reachable, no processing errors, aligned with public URLs.
• ☐ URL inspection in GSC: «URL is on Google» for home + 3 business URLs.
• ☐ Declared canonical = Google-selected canonical (no mass conflicts).
• ☐ No unexplained spikes of «Discovered — not indexed» or «Duplicate» in the pages report.
• ☐ Correct HTTP responses: 200 on content, 301 (not long chains) on migrations, clean 404s where needed.

Red flag: product or blog templates with historical traffic moving to «Excluded» after a deploy. For the full workflow, see step 1 of our step-by-step technical audit.

Phase 2 — Architecture and URLs

• ☐ HTTPS sitewide; one canonical host variant (www vs non-www, consistent trailing slash).
• ☐ Redirects: at most one 301 hop per migrated URL; no loops or mistaken permanent 302s.
• ☐ Click depth: important pages within ≤3 clicks from home.
• ☐ Readable, stable slugs in the correct language (no mixed /es/blog/english-slug/).
• ☐ Multilingual: reciprocal, coherent hreflang when you have ES/EN or other locales.
• ☐ Parameters, filters, and sort orders do not spawn thousands of indexable duplicates.
• ☐ Preview, staging, or API subdomains not indexable or linked from production.
• ☐ Sitemap and internal links target the public domain, not a hidden CMS.

Phase 3 — Technical on-page

Walk each template in your sample (home, landing, article):

• ☐ One clear <h1> per URL; logical H2/H3 hierarchy.
• ☐ Unique <title> (~50–60 useful characters) and meta description that earns clicks without filler.
• ☐ Self-referencing canonical unless explicit syndication rules apply.
• ☐ Main content visible in initial HTML (View Source shows headline and body).
• ☐ Images with descriptive alt; modern formats (WebP/AVIF) when possible.
• ☐ Basic Open Graph and Twitter Card on shareable templates.
• ☐ Pagination with crawlable links or clear signals (not JS-only buttons without fallback).
• ☐ No mass duplicate titles or descriptions in the crawl sample.

Phase 4 — Performance and Core Web Vitals

Google uses experience signals; LCP, INP, and CLS summarize loading, responsiveness, and stability. On the checklist:

• ☐ PageSpeed Insights on mobile for the 3–5 URLs with most impressions or conversion.
• ☐ Search Console Core Web Vitals report without «Poor» URLs on business templates.
• ☐ LCP: main element identified (hero, product image, headline) and optimized.
• ☐ INP: key interactions (menu, filters, CTA) without long main-thread blocks.
• ☐ CLS: images and embeds with reserved dimensions; banners that do not push content.
• ☐ Reasonable TTFB on dynamic templates (do not confuse spot cache with real performance).
• ☐ Third parties reviewed: analytics, chat, tags — load after critical content when possible.

Deeper concepts: Core Web Vitals explained: what to measure. For a concrete speed workflow, follow our practical PageSpeed audit guide.

Want a quick snapshot before the long report? On our technical SEO landing you can use the PageSpeed simulator on a sample URL.

Phase 5 — Internal links and structured data

Internal links

• ☐ New pages linked from home, blog, or relevant landings.
• ☐ No broken links (404) in menus, footer, or legacy content.
• ☐ Descriptive anchors on contextual links (not just «click here»).
• ☐ Topic cluster: related articles cross-link (audit, speed, architecture).

Structured data

• ☐ Organization / WebSite on home without critical errors.
• ☐ Article or BlogPosting on blog posts.
• ☐ FAQPage only where questions are visible on the page.
• ☐ Product, LocalBusiness, or other types only when they match the real business.
• ☐ Rich Results Test with no errors blocking the expected result type.

Implementation guide on modern stacks: Schema.org with Next.js.

How to score and prioritize findings

When you finish all five phases, do not open twenty tickets at once. Classify each finding:

Severity	Checklist examples	Action
Critical	Mass noindex, 5xx, migration without 301s, robots.txt blocking /blog/	Pause campaigns; fix within hours or days
High	Wrong canonical, broken sitemap, «Poor» CWV on money URLs	Current sprint
Medium	Duplicate titles, heavy images, secondary broken links	Backlog 2–4 weeks
Low	Optional schema, micro alt-text tweaks	When capacity allows

Deliver a doc with: URL, evidence (screenshot or export), severity, owner (dev, content, infra), and definition of done. An SEO audit checklist that does not become concrete actions is just a pretty list in Notion.

If after the checklist you consider outside help, see technical SEO pricing to understand models and what a serious quote should include.

Mistakes that invalidate the audit

Measuring only home on desktop with perfect WiFi

Templates that scale (category, product, article) often fail on mobile while home looks fine.

Confusing Lighthouse score with SEO

A lab 100 does not guarantee rankings. Field CWV and indexing matter just as much.

Ignoring initial HTML

If View Source is empty and content only appears after JavaScript, on-page checks may pass in DevTools but fail for Google.

Fixing schema before canonicals

Rich results do not compensate for duplicate or non-indexed URLs. Respect phase order.

Not rerunning the checklist after major changes

Redesigns, new plugins, or headless migrations require another pass — do not assume «we did this in January».

FAQ

How long does this checklist take?

With a 10-URL sample and tools open: half a day to one day for someone who knows the project. Large sites need automated crawls and dev validation — two to five days.

Checklist vs full SEO audit?

The checklist is the operational skeleton; a full audit adds depth (external links, content, competition). Start here if you need quick order; go deeper with the step-by-step guide if traffic dropped.

Can I automate part of the list?

Yes: scheduled crawls, uptime alerts, Lighthouse in CI, CWV reports. Interpreting canonicals, hreflang, and product changes still needs human judgment.

How often should I repeat it?

Quarterly on active sites; monthly during migrations or major launches. Search Console alerts help but do not replace scheduled reviews.

What do I do after checking everything?

Prioritize critical and high items, assign owners, and measure again in 4–6 weeks. For speed, rerun PageSpeed Insights or the SEO landing simulator on the same sample URLs.

In product meetings or agency calls, the question always shows up: static or dynamic pages for SEO. It sounds technical, but it really boils down to this: does Google get clear, fast HTML — or a shell that only fills in after JavaScript runs?

You will not find code here. We want you to understand what each option means, what Google cares about, and when mixing approaches makes sense — as many modern sites do with static generation plus periodic updates.

Table of contents

• What static and dynamic mean for SEO
• What Google sees in each case
• SSG, SSR, CSR, and ISR — plain language
• When static makes sense
• When you need dynamic
• The hybrid approach (most common today)
• Mistakes we see often
• Quick checklist before deciding
• Common myths
• FAQ

What static and dynamic mean for SEO

A static page (SEO sense): the server delivers HTML that is largely ready. The main content — headline, body copy, links — is already there in the response. Google does not have to wait for JavaScript to assemble the page from scratch.

A dynamic page: HTML is built on each request, or most content appears later in the browser after scripts and data load. That can be perfect for a user dashboard; for a landing page you want to rank, it needs extra care.

Important: «static» does not mean «never changes». A homepage regenerated every five minutes with new posts is still static for Google if each visit gets full HTML. What matters is what the crawler receives, not the framework label.

What Google sees in each case

Google crawls millions of URLs. To decide whether to index and rank, it needs:

• HTML with substance — headings, paragraphs, internal links.
• Fast responses — slow pages eat crawl budget.
• Consistent signals — canonicals, meta descriptions, hreflang when you have locales.

If your dynamic page returns empty HTML and text only appears after JavaScript, Google can render it — but slower, with more failures, and at a disadvantage versus an equivalent static URL.

Simple test: open your URL → right-click → View page source (not DevTools). Do you see the headline and article body? If yes, you are on the right track. If you only see an empty container, you have SEO work ahead.

SSG, SSR, CSR, and ISR — plain language

Engineering teams use acronyms. Translated for SEO:

Approach	What happens	SEO in one line
SSG (static)	HTML built ahead of time, served as-is	Very friendly: fast and predictable for crawlers
SSR (server dynamic)	HTML generated on each request on the server	Good if the server is fast and HTML arrives complete
CSR (browser dynamic)	Minimal HTML; JavaScript paints content	High risk without pre-rendering or fallback
ISR (hybrid)	Static pages regenerated on a schedule	Common balance: speed plus updatable content

If you are weighing Next.js against classic WordPress, our Next.js vs WordPress for SEO comparison fits here. If you already split CMS and frontend, headless WordPress with Next.js explains how that split works.

When static makes sense

Prioritize pre-rendered HTML when:

• Content changes slowly — service landings, legal pages, published blog posts.
• Organic traffic matters — you want low LCP and efficient crawling.
• The same URL serves almost everyone the same thing — no per-user personalization.
• You have many URLs — catalogs, blogs with hundreds of posts; generate once, serve fast scales better.

Static pages often score better on Core Web Vitals because they deliver fewer loading surprises. That does not guarantee position one, but it removes a common friction point.

When you need dynamic

Not everything can — or should — be static:

• Real-time data — stock, prices that change every minute, appointment availability.
• Session content — logged-in areas, carts, history-based recommendations.
• Heavy personalization — dashboards, B2B portals, complex on-site search results.
• Interactive flows — forms, product configurators.

The SEO key: separate indexable from functional. A product page can be static or ISR; dynamic checkout does not need to rank. Mixing both worlds deliberately avoids blocking conversions by forcing SSG on the entire site.

The hybrid approach (most common today)

Most serious projects do not pick «all static» or «all dynamic». They combine:

• Blog and landings → static generation or ISR (fast, indexable).
• APIs and logged-in areas → dynamic (where live experience matters).
• Periodic revalidation → fresh content without rebuilding the whole site on every click.

That hybrid is what many teams want when moving off monolithic WordPress to a modern frontend: keep the editorial workflow, gain speed on public pages. To check whether it is working, our practical PageSpeed audit guide helps you measure results.

Mistakes we see often

Rendering everything client-side «because it is modern»

SPAs without pre-rendering: Google may index, but you compete with sites that deliver HTML instantly. For content or transactional SEO, it is usually a poor bet.

Static at build time, empty in production

Generating pages at deploy but not pulling real CMS data — sitemap URLs with placeholder or stale content.

Confusing cache with static

Cached PHP feels static, but when cache misses, TTFB spikes. Measure real behavior, not just the stack label.

Indexing URLs that should stay private

Dynamic account areas, session parameters, or infinite filters creating duplicates. Dynamic architecture needs clear canonical and robots rules.

Quick checklist before deciding

1. Which URLs need to rank on Google? (short list)
2. Does View Source on those URLs show the main content?
3. How often do they change? (daily / weekly / rarely)
4. Is there per-user personalization on those same URLs?
5. Does Search Console crawl stats show errors or slowness?
6. Have you measured mobile LCP on key templates?

If most strategic URLs change slowly and should rank, lean static or ISR. If they live on live data, design dynamic with SSR or a clear split of indexable routes.

Common myths

«Google does not index JavaScript»

It does render JS, but with delay and limits. That is not the same as HTML from the first byte.

«Static means outdated»

With scheduled revalidation, a static blog can update in minutes without losing speed.

«Dynamic is always slower for SEO»

Well-built SSR on a nearby server can be excellent. What hurts SEO is pure CSR on pages that should index.

«You must pick one for the whole site»

Mature projects mix by page type. The right question is «should this specific URL be static or dynamic?»

FAQ

Do static pages rank better than dynamic ones?

There is no «static» ranking factor. What helps is speed, crawl-accessible HTML, and content quality — and static often makes those three easier.

Is classic WordPress static or dynamic?

Dynamic at source (PHP builds HTML per request), though cache plugins make it behave like static. For Google, the measured result matters, not the label.

What is ISR and why is it mentioned with SEO?

It regenerates static pages on an interval. Combines pre-rendered speed with content that updates without a full site rebuild.

Should I migrate my SPA to static for SEO?

It depends. If URLs you want to rank do not show content in View Source, consider pre-rendering, SSR, or hybrid routes before a full redesign.

How do I know if my choice works?

Search Console (indexing, CWV), View Source on key templates, and a speed audit on URLs with traffic or commercial intent. For structure, start with our technical SEO audit step by step.

“How much does technical SEO cost?” is one of the first questions when a site grows, migrates platforms, or stops ranking. The honest answer: it depends — on project size, current health, and whether you need a one-off report or ongoing support.

This guide explains what each pricing model usually includes, what variables raise the bill, and how to read a quote without confusing technical SEO with generic “rank higher” packages.

Table of contents

• Technical SEO vs “general” SEO
• Engagement models
• What raises or lowers cost
• Market ranges (2026, indicative)
• What a solid quote should include
• Monthly retainers: when they make sense
• Red flags when comparing prices
• FAQ

Technical SEO vs “general” SEO

Technical SEO covers the layer that lets Google crawl, index, and evaluate your site: architecture, speed, Core Web Vitals, canonicals, sitemap, structured data, HTTPS, redirects, and more. It is not blog writing or social media management.

A cheap “10 keywords + 4 posts per month” package rarely fixes a broken migration or critical mobile INP. If your issue is indexing or performance, budget for a real technical SEO audit, not content alone — or start with our SEO audit checklist for developers.

Related: practical PageSpeed audit guide and Core Web Vitals explained.

Engagement models

Model	What it is	Best for
One-off audit	Diagnosis + prioritized report; implementation optional	Pre-migration baseline, due diligence, second opinion
Fixed project	Audit + agreed fix bundle (e.g. CWV on key templates)	Redesigns, store launches, recovering from technical debt
Monthly retainer	Recurring hours: monitoring, new URLs, dev support	Active sites, e-commerce, teams that ship often
Agency + tooling hybrid	Human retainer plus dashboard/SaaS tracking	Teams wanting continuous data without building a stack

What raises or lowers cost

Site volume and complexity

• Dozens of URLs vs thousands (e-commerce, filters, pagination).
• Multilingual (hreflang, distinct slugs, headless CMS).
• Subdomains or indexable staging environments.

Starting condition

• Recent migration without complete 301s.
• History of penalties or technical spam.
• Plugin bloat, mass duplicates, intermittent 5xx.

Implementation depth

Report-only is cheaper than report + dev tickets + post-deploy validation. If your team has no capacity, total technical SEO pricing rises because the consultant coordinates with engineering.

Vertical and competition

Saturated markets (legal, finance, national e-commerce) need more performance and architecture iteration — not because Google charges more, but because margin for error is smaller.

Market ranges (2026, indicative)

Very approximate figures for professional services in US/EU markets — not DIY tool subscriptions. Use them to calibrate expectations; every provider structures differently.

Service	Indicative range	Notes
Technical audit (small site)	$900 – $3,000	~50–200 URLs, report + prioritization call
Technical audit (mid/large)	$3,000 – $10,000+	E-commerce, multilingual, multiple environments
CWV + indexation fix project	$3,500 – $18,000+	Dev hours drive cost; often phased
Monthly technical SEO retainer	$700 – $3,500+/mo	Included hours, SLA, GSC/CWV monitoring

LatAm and smaller EU markets may sit below US bands for similar relative complexity. Suspiciously cheap quotes without defined scope usually cost more in rework.

What a solid quote should include

1. Explicit scope: URLs audited, templates, languages, tools.
2. Deliverables: report, prioritized list (critical / high / medium), not screenshots only.
3. Implementation hours or who executes (client vs agency).
4. Post-change validation: re-crawl, GSC, PageSpeed on agreed URLs — see how to run a PageSpeed audit and our technical SEO audit step by step.
5. Ownership: access, exports, documentation for your team.

If the quote never mentions indexing, CWV, or schema, it may not be pure technical SEO. To know what to check before paying, see SEO for developers: what to measure first.

Monthly retainers: when they make sense

A retainer fits when:

• You publish blog or catalog content often (new URLs to index).
• Your product roadmap touches frontend (A/B tests, third parties, features).
• You want Core Web Vitals and crawl error monitoring without waiting for quarterly reviews.
• You need a technical voice in dev or performance agency meetings.

It fits less when the site is static, rarely changes, and fixes from a clear audit are already shipped — then a one-off audit plus annual check is enough.

Red flags when comparing prices

• “Guaranteed rankings” in X days — serious providers do not promise that.
• Flat price without asking site size or GSC access.
• 100% automated report with no human review.
• Mixing technical SEO with link buying / PBNs.
• No split between audit and implementation (mid-project surprises).

FAQ

Does technical SEO pricing include content?

Usually not. Some agencies sell blended packages; clarify whether hours go to copy or crawl, speed, and indexing work.

Can I buy the audit only and implement in-house?

Yes — common for teams with developers. Ensure the report translates findings into actionable tickets.

How fast is ROI?

Indexation fixes can show impact in weeks; CWV in ~28-day field data cycles; content authority takes longer. Technical SEO unblocks; it does not replace editorial strategy.

Do SaaS tools replace an agency?

They complement. Dashboards help monitor; they do not prioritize a failed migration or negotiate with backend teams. Many retainers combine both.

How to budget a WordPress → headless migration?

Pre-migration audit + 301 plan + post-launch validation. Usually a project, not retainer alone. Context in headless WordPress with Next.js.

Google understands text, but also structured data: labels that describe what each page is (article, company, FAQ, product…). Schema.org is the most widely used standard vocabulary. On Next.js projects — especially headless or hybrid setups — it often makes sense because you control the HTML search engines receive without relying on a plugin injecting generic markup.

This guide explains the SEO upside, which types to prioritize, and mistakes to avoid. It is not a code manual: it is the map you need before talking to engineering or validating an audit.

Table of contents

• What Schema.org is
• Why it fits Next.js and headless sites
• JSON-LD, microdata, and RDFa
• Schema types that matter most for SEO
• Rich results: what you can gain (and what you cannot)
• How to validate before launch
• Common mistakes
• FAQ

What Schema.org is

Schema.org is a set of types and properties agreed by search engines and the industry to describe web content. Examples:

• A blog post → Article or BlogPosting.
• An agency home page → Organization + WebSite.
• Visible Q&A blocks → FAQPage.
• A store product → Product with price and availability.

It does not replace strong titles, meta descriptions, or useful content. It is a context layer: it helps Google classify the page and, in some cases, show enriched results (stars, expandable FAQ, breadcrumbs in SERPs).

In a technical SEO audit, schema is usually reviewed in the structured-data step — after indexing and performance, but before scaling content.

Why it fits Next.js and headless sites

On classic WordPress, plugins like Yoast or Rank Math generate JSON-LD automatically. When the CMS stores content and Next.js serves the public frontend (as in many headless WordPress with Next.js projects), structured markup becomes the responsibility of whoever builds public templates.

Conceptual advantages on Next.js:

• Consistency: the same schema pattern across routes (blog, landings, contact).
• Dynamic data: post title, date, image, and author can feed BlogPosting from the CMS API.
• Fewer duplicates: avoid CMS and frontend injecting conflicting JSON-LD blocks.
• QA control: validate schema on staging before deploy, like canonicals or hreflang.

The keyword schema.org nextjs does not mean Next.js has “magic SEO”: it means you have freedom — and responsibility — to define the structured layer well.

JSON-LD, microdata, and RDFa

Google recommends JSON-LD: a <script type="application/ld+json"> block in HTML, separate from visible content. It is easier to maintain than microdata sprinkled through every tag.

Format	Pros	Cons
JSON-LD	Clean, versionable, ideal for SPAs and SSR	Must reflect real on-page content
Microdata	Tied to visible HTML	Verbose; easy to break when templates change
RDFa	Flexible for complex XML/HTML	Rare in modern stacks

Schema types that matter most for SEO

Corporate / agency site

• Organization — name, logo, URL, social profiles (sameAs).
• WebSite — site entity and optional internal search action.
• LocalBusiness — only with a verifiable physical location; do not invent addresses.

Blog and content

• BlogPosting or Article — headline, datePublished, author, image.
• BreadcrumbList — visible breadcrumbs aligned with the URL.

Service landings

• Service — service description, provider (Organization).
• FAQPage — only when questions are visible in HTML (not hidden for bots alone).

E-commerce (when relevant)

• Product, Offer, AggregateRating — real data only; fake reviews hurt.

Prioritize types that match high-traffic templates: home, articles, service pages. Adding ten irrelevant types does not improve rankings.

Rich results: what you can gain (and what you cannot)

Rich results are snippets with expandable FAQ, stars, breadcrumbs, etc. Google decides whether to show them; schema only makes you eligible.

• Visible FAQ → possible accordion in SERPs (when Google finds it helpful).
• Well-marked article → better understanding; no guarantee of Top Stories carousel.
• Product + genuine reviews → stars in some markets.

Schema does not replace Core Web Vitals or internal links. It is one more piece of the technical puzzle.

How to validate before launch

1. Google’s Rich Results Test — live URL or HTML snippet.
2. Search Console → Enhancements / structured data — errors and rich-result impressions.
3. Manual check: view source and confirm one coherent block per primary type.
4. Page alignment: dates, images, and author in JSON-LD must match what users see.
5. After each deploy — same as checking canonicals after migrations.

For other technical signals, pair this review with our SEO DevTools for developers guide and, for speed, the practical PageSpeed audit guide.

Common mistakes

• FAQPage without visible FAQ — spam policy risk; Google may ignore the block.
• Duplicating Organization on every URL with conflicting data — confuses Google.
• Empty required fields — image, author, datePublished on articles.
• CMS schema + frontend schema on headless without coordination — duplicates or conflicts.
• Invented Product/Review markup — can trigger manual actions.
• Treating schema as a direct ranking boost — eligibility help, not a guaranteed lift.

FAQ

Is Schema.org required to get indexed?

No. Pages without schema index normally. Structured data improves understanding and sometimes SERP presentation.

Does Next.js include Schema.org by default?

Not automatically on every route. It depends on how you build metadata and scripts per template, or what your CMS exposes via API.

Does Yoast still matter for schema in headless?

Many headless setups read SEO fields from the CMS (title, meta, opengraphImage). JSON-LD may be generated on the frontend, in the CMS, or both — one coherent source of truth matters most.

How many schema types per page?

One clear primary type (Article, Service, FAQPage…) plus logical nested types (Organization as publisher). Avoid listing types unrelated to the content.

How often should I review it?

On every new template, redesign, or CMS change. Quarterly on stable sites, as part of the schema step in a technical audit.

A PageSpeed audit is not a vanity score for social media — it is how you measure how fast and stable your site feels, read the report, and decide what to optimize first. If you only chase green or red numbers without context, you will change hosts or install plugins at random.

This guide is practical — focused on PageSpeed Insights, Lighthouse, and Google’s field data — and fits as the performance chapter inside a broader technical SEO audit. You can also run our SEO audit checklist for developers as an actionable list. It does not replace indexing or link checks; it complements the Core Web Vitals step.

Table of contents

• What a PageSpeed audit is
• PageSpeed vs a full SEO audit
• Tools you will use
• Lab data vs field data
• Audit steps (workflow)
• Reading LCP, INP, and CLS in the report
• What to fix first
• Common mistakes
• FAQ

What a PageSpeed audit is

It is a diagnosis focused on perceived performance and experience metrics: how long until main content is visible (LCP), how responsive interactions feel (INP), and how stable the layout is (CLS). Google surfaces much of this in PageSpeed Insights and Search Console under Core Web Vitals.

The goal is not “getting 100” in Lighthouse, but to:

• Spot problematic templates (home, categories, product detail, key landings).
• Separate server, frontend, image, and third-party issues.
• Prioritize changes that help real users and, as a side effect, SEO.

If the acronyms are still fuzzy, read Core Web Vitals explained: what to measure and why SEO cares before going deeper.

PageSpeed vs a full SEO audit

PageSpeed audit	Full technical SEO audit
Speed, CWV, render-blocking resources, page weight	Indexing, canonicals, sitemap, architecture, schema, links
Hours to a few days per key template	Days to weeks depending on site size
Great after redesigns, bounce spikes, or before paid campaigns	Essential before migrations and before scaling content or link building

You can run a PageSpeed audit alone when mobile traffic drops or Search Console flags URLs in red under Experience. If you also have mass “Discovered — not indexed”, fix crawl access first with our technical SEO audit step by step before obsessing over the Lighthouse score.

If you need a budget for implementation or a monthly retainer after measuring speed, see technical SEO pricing for indicative ranges and what a serious quote should include.

Tools you will use

• PageSpeed Insights (PSI): public URL, blends field data (CrUX when available) and lab Lighthouse.
• Lighthouse in Chrome DevTools: repeatable locally or on staging; ideal for before/after deploys.
• Google Search Console: Core Web Vitals report by URL groups — aggregated Chrome user data.
• WebPageTest or similar (optional): detailed waterfall, locations, and throttled connections.

For day-to-day dev work, pair PSI with our SEO DevTools for developers guide — Network, Coverage, and Performance tabs fill in what PSI summarizes.

Lab data vs field data

Lab: controlled simulation (device, network, test location). Repeatable. Best for debugging after a deploy.

Field: anonymized real-user measurements (Chrome User Experience Report). Reflects actual devices, networks, and caches. Search Console uses field data to label URLs good / needs improvement / poor.

Practical rule: do not celebrate a 98 Lighthouse score if Search Console still shows poor LCP on the same template. Re-test on mobile, throttled 4G, and the exact URL that ranks.

Audit steps (workflow)

1. Pick 5–10 URLs: home, main landing, a traffic blog post, a listing template, and one URL you already know is slow.
2. Pick the device: start with mobile; desktop only if your business is overwhelmingly desktop B2B.
3. Run PSI on each URL; screenshot or export top opportunities. As a shortcut, test your domain first in the PageSpeed simulator on our technical SEO landing.
4. Note the three CWV (field when available; otherwise lab) and the LCP element PSI highlights.
5. Group by template: if ten products fail the same way, fix the template — not ten one-off tickets.
6. Bucket opportunities: images, JavaScript/CSS, server/network (TTFB, cache, CDN).
7. Ship 1–2 high-impact changes; re-measure the same URL under the same conditions.
8. Document URL, date, scores/metrics, and what changed — essential when working with agencies or external devs.

Reading LCP, INP, and CLS in the report

If you need a refresher on what each metric means and Google’s thresholds, revisit Core Web Vitals explained: what to measure before diving into PSI opportunities.

LCP (loading)

PSI shows which element was “largest contentful” (hero, image, text block). Ask: oversized image? slider? slow server response? Opportunities like “Improve image delivery” or “Reduce initial server response time” often point here.

INP (interactivity)

Matters for menus, filters, carts, and SPAs. If INP fails with little visible JavaScript, suspect third-party scripts (chat, tags, A/B tools) blocking the main thread.

CLS (visual stability)

Look for unsized images, late-injected banners, and fonts that shift layout. PSI sometimes lists “elements causing largest layout shifts.”

Lighthouse also scores Accessibility, Best Practices, and SEO categories. For a business-focused PageSpeed audit, Performance + CWV come first; the rest helps but does not replace fixing LCP on the landing that converts.

What to fix first

Signal	Typical actions (stack-agnostic)
High TTFB	HTML caching, CDN, hosting closer to users, less work at origin
LCP = hero image	Compression, responsive sizing, careful preload, avoid heavy above-the-fold carousels
Blocking JS	Defer non-critical scripts, split bundles, audit plugins injecting global scripts
CLS	Reserve space for media and ads; avoid inserting bars over main content
INP	Lighten heavy handlers, optimize listeners, limit third-party widgets on key pages

Suggested order for most corporate sites and blogs: server/cache → LCP images → third-party scripts → CLS → INP polish. E-commerce and marketplaces sometimes swap INP and LCP priority because of cart complexity. Once prioritized, validate impact with Veloce Devs’ SEO simulator and audit tools before opening dev tickets.

Common mistakes

• Auditing only the homepage while organic traffic lands on slow blog posts or categories.
• Optimizing desktop while Google evaluates mobile-first.
• Treating Lighthouse score as a ranking switch — it helps, but it is not a direct dial.
• Installing a “PageSpeed plugin” that minifies blindly — often hurts INP or breaks features.
• Not re-testing after changes, or testing under different conditions (network, browser extensions).
• Ignoring field data when Search Console already has enough volume.

FAQ

How long does a basic PageSpeed audit take?

For 5–10 URLs and a prioritized write-up, budget half a day of analysis plus another half day if you include dev meetings. Implementation depends on your team — hours to several weeks.

Is PageSpeed Insights free?

Yes. Lighthouse in Chrome is free too. Search Console is free with domain verification. Advanced waterfall tools may be paid but are not required to start.

What PageSpeed score do I need to rank?

There is no single public threshold. Google works with Core Web Vitals ranges and broader experience signals. Aim for “good” in the field on main templates, not a round lab number.

PageSpeed audit on staging or production only?

Production reflects CDN, real cache, and third parties. Staging helps validate fixes before release, but always re-check the public URL after deploy.

How often should I repeat it?

After major design, plugin, or script changes. In steady state, monthly or quarterly checks on the same “canary” URLs plus Search Console’s CWV report.

A technical SEO audit answers one concrete question: can Google find, crawl, understand, and index your site without friction? It does not replace content strategy, but it prevents months of editorial work from vanishing because of a bad robots.txt, redirect chains, or templates that duplicate URLs.

This guide proposes a logical order — from blockers to fine-tuning — for marketing and engineering teams who want a clear map before opening tickets or hiring outside help.

Table of contents

• What a technical SEO audit is
• When to run one
• Step 1 — Crawling and indexing
• Step 2 — Architecture and URLs
• Step 3 — On-page and indexable content
• Step 4 — Performance and Core Web Vitals
• Step 5 — Internal and external links
• Step 6 — Structured data and SERP
• How to prioritize findings
• FAQ

What a technical SEO audit is

It is a systematic diagnosis of your site’s technical layer: not whether your copy persuades, but whether the infrastructure lets search engines do their job. It typically covers:

• Indexing status and crawl errors.
• Canonicals, hreflang, and duplicates.
• Speed, visual stability, and interactivity (Core Web Vitals).
• Sitemap, robots.txt, and HTTP responses.
• Schema markup and rich result eligibility.

It differs from a content audit (keywords, search intent) and an authority audit (backlinks). All three complement each other; technical usually comes first because a non-indexed site competes for no query.

When to run one

Timing	Why
Before a redesign or migration	Baseline indexed URLs, redirects, and organic traffic
After a sharp traffic drop	Spot blocks, 5xx, accidental noindex, or aggressive canonicals
New section launch	Blog, store, languages — validate architecture from day one
Quarterly review	Plugins, themes, and new content degrade SEO silently
Before link building spend	Do not send authority to pages with technical leaks

Step 1 — Crawling and indexing

Start with Google Search Console (correct domain or URL-prefix property):

1. Indexed vs excluded pages: are useful URLs growing? spikes of “Duplicate” or “Redirect”?
2. Pages report: filter 404, 5xx, “Discovered — not indexed”.
3. Sitemaps: does submitted XML match public URLs? processing errors?
4. URL inspection: test home, categories, and 3–5 money URLs — declared vs Google-selected canonical.

Complement with a site crawl (Screaming Frog, Sitebulb, or similar) to see bot-level response codes, meta robots, HTML canonicals, and click depth.

Step 2 — Architecture and URLs

• HTTPS everywhere; one canonical host variant (www or not, consistent trailing slash).
• Redirects: short chains (ideally one 301 hop); avoid loops and mistaken permanent 302s.
• Depth: important pages within ≤ 3 clicks from home.
• Multilingual: coherent hreflang across locales without mixed-language slugs.
• Parameters and filters: do they create indexable duplicates? use canonical or noindex where needed.

If blog and landings live on different routes, confirm sitemap and internal links target the public site — not a CMS or preview subdomain.

Step 3 — On-page and indexable content

For each key template (home, service, article):

• One clear <h1>; logical H2/H3 hierarchy.
• Unique title and meta description; title ~50–60 useful characters; description that earns clicks without filler.
• Self-referencing canonical unless syndication rules say otherwise.
• Main content visible in initial HTML (not only after heavy JS interaction).
• Images with descriptive alt; modern formats (WebP/AVIF) when possible.

To go deeper on what to measure before copy, see SEO for developers: what to measure first and SEO DevTools for developers.

Step 4 — Performance and Core Web Vitals

Google uses experience signals; Core Web Vitals (LCP, INP, CLS) summarize loading, responsiveness, and stability. In the audit:

1. Measure real URLs in PageSpeed Insights or field reports in Search Console.
2. Prioritize templates with the most organic traffic or conversion.
3. Split mobile and desktop — mobile-first remains the main reference.
4. Document LCP element, render-blocking scripts, and unsized images (CLS).

Conceptual background in Core Web Vitals explained: what to measure and why SEO cares. To move from broad diagnosis to a concrete speed workflow, follow our practical PageSpeed audit guide. If you are weighing outside help, see technical SEO pricing for typical models and what quotes should include. For an actionable list your team can run through, use our SEO audit checklist for developers.

Step 5 — Internal and external links

Internal

• Do new pages get links from home, blog, or landings?
• Broken links (404) in menus, footers, or legacy content?
• Descriptive anchors vs generic “click here”?

External

• Toxic backlink patterns or suspicious spikes (Ahrefs, Semrush, etc.).
• Broken outbound links in cited resources.

Step 6 — Structured data and SERP

Validate JSON-LD or microdata with Google’s Rich Results Test:

• Organization / WebSite on home.
• Article or BlogPosting on posts.
• FAQPage only when questions are visible on the page.
• Product / LocalBusiness when relevant to your business.

Schema errors rarely block indexing but can block rich results — fix them when the page type justifies it.

How to prioritize findings

Severity	Examples	Action
Critical	noindex on money templates, mass 5xx, migration without 301s	Pause campaigns; fix within hours or days
High	Wrong canonical, broken sitemap, CWV far below threshold	Current sprint
Medium	Duplicate titles, heavy images, secondary broken links	Backlog 2–4 weeks
Low	Optional schema, micro alt-text tweaks	When capacity allows

Deliver a doc with: affected URL, evidence (screenshot or export), estimated impact, and owner (dev, content, infra). A technical SEO audit that does not become actionable tickets is just a decorative PDF.

FAQ

How long does a technical SEO audit take?

A small site (dozens of URLs) can be reviewed in 1–2 analysis days. E-commerce, multilingual, or thousands-of-URL projects need longer crawls and dev validation — one to three weeks depending on depth.

What is the minimum toolset?

Google Search Console is mandatory. Add a desktop crawler, PageSpeed Insights, and browser DevTools. Paid suites help with links and tracking but are not required for a first pass.

Technical audit vs content audit?

Technical validates access and indexing; content evaluates keywords, intent, editorial quality, and contextual links. Do technical first if you suspect blockers; if traffic grows but does not convert, balance with content and UX.

How often should I repeat it?

Quarterly for active sites; monthly during migrations or major launches. Search Console alerts help but do not replace scheduled reviews.

Can I automate part of the process?

Yes: scheduled crawls, uptime alerts, CWV reports in CI. Interpretation and prioritization still need human judgment — especially for canonicals, hreflang, and product changes.

The question Next.js vs classic WordPress for SEO shows up in almost every product meeting: migrate, stay put, or mix both? There is no universal answer. Google does not rank a framework — it ranks pages that are useful, fast, well linked, and technically sound. What changes is how much effort each approach takes to get there.

This guide compares both paths through SEO and operations: what you control, what typically breaks, and when each option fits. If you want a third path (WordPress as CMS + modern frontend), we point to a dedicated article on headless WordPress with Next.js below.

Table of contents

• What you are actually comparing
• Technical SEO: classic WordPress vs Next.js
• Performance and Core Web Vitals
• Content, plugins, and maintenance cost
• When to choose WordPress, Next.js, or hybrid
• Checklist before changing stacks
• Common myths
• FAQ

What you are actually comparing

Classic WordPress is a full stack: you create content in the dashboard and a theme (PHP) renders what users and Google see. Plugins add SEO, cache, forms, commerce, and more.

Next.js is a framework for the web layer (pages, routing, interactivity). It does not ship an editorial panel out of the box — content may come from a CMS, files, a database, or APIs. For SEO, what matters is the HTML delivered to crawlers, not the framework name.

In practice, nextjs vs wordpress seo often blends three different scenarios:

• WordPress with theme + Yoast (or similar) — the most common case.
• Next.js with static content or a headless CMS — maximum frontend control.
• Headless WordPress + Next.js — edit in WP, ship an optimized public site.

Confusing “pure Next.js” with “headless” leads to unrealistic budgets and timelines. Clarify that before asking for quotes.

Technical SEO: classic WordPress vs Next.js

SEO factor	Classic WordPress	Next.js (well executed)
Titles and meta descriptions	Mature SEO plugins, familiar UI for marketing	Full control in templates; needs discipline or CMS SEO fields
URLs and canonicals	Common patterns; duplicate risk when plugins misconfigured	Explicit routes; fewer surprises if architecture is planned
Sitemap and robots	Automatic generation via plugins	Manual or library-driven; highly flexible
Structured data	Plugins add JSON-LD; quality varies	Custom schema per template; more upfront work, more precision
Multilingual	Plugins (Polylang, WPML) widely used	Feasible, but hreflang and routes must be designed from day one
JS indexing	Less JS on light themes; heavy themes complicate	SSR/SSG serves full HTML; ideal for crawlers when not client-only

Neither column wins everywhere. WordPress shortens the path for teams that live in the dashboard. Next.js rewards teams that want a custom web product without dragging a generic theme’s weight.

To prioritize what to measure before debating frameworks, see SEO for developers: what to measure first.

Performance and Core Web Vitals

Speed is not the only ranking factor, but Core Web Vitals reflect real experience — especially on mobile. That is where classic WordPress often struggles: multipurpose themes, page builders, dozens of active plugins, and scripts loaded on every URL.

Next.js is not magic: a poorly optimized frontend (huge images, uncontrolled fonts, excessive hydration) also fails PageSpeed. The advantage is you can design each page to load only what it needs, with server or static rendering when it helps.

• LCP: WordPress improves with hosting, cache, and image optimization; Next.js with responsive images, CDN, and priority HTML.
• INP / interactivity: Less third-party JavaScript on a dedicated frontend usually helps.
• CLS: Solid themes vs careless builders can break layout; in Next.js it depends on components and reserving space for media.

Go deeper on meaning and interpretation in Core Web Vitals explained: what to measure and why SEO cares.

Content, plugins, and maintenance cost

SEO does not end at launch. Someone publishes posts, updates landings, fixes broken links, and plans redirects when URLs change.

Classic WordPress

• Pros: low editorial learning curve, plugin ecosystem, WordPress-skilled hires are common.
• Cons: plugin/theme updates, conflicts, security, performance drift without a technical owner.

Next.js

• Pros: modern codebase, CI/CD, fewer “plugin X broke SEO” surprises.
• Cons: developers needed for structural changes; without a CMS, marketing depends on tickets for simple edits.

The hidden SEO cost is usually maintenance, not theme licensing. Well-governed WordPress can last years; undocumented Next.js becomes a black box.

When to choose WordPress, Next.js, or hybrid

Scenario	Guidance
Small corporate site or blog, few templates, non-technical team	Classic WordPress + light theme + SEO plugin + cache
Standard WooCommerce store with many payment/shipping extensions	Classic WordPress (headless here often adds pain without clear upside)
Aggressive CWV marketing, custom landings, interactive tools	Next.js or headless with a known CMS
Strong WordPress editorial team but slow site because of the theme	Headless hybrid — keep the dashboard, rebuild the frontend
Startup still validating product and content	Avoid over-engineering; solid WordPress or minimal Next.js landing until traction
Serious multilingual SEO (ES/EN/+) with paired translated URLs	Both work; WordPress + language plugin is the fast path; Next.js needs hreflang design on day one

If your row is “hybrid,” the next conceptual step is headless WordPress with Next.js — not the only way to combine both, but the most common pattern in 2026.

Checklist before changing stacks “for SEO”

1. Baseline: Search Console + PageSpeed on URLs that matter (home, categories, top posts).
2. Honest diagnosis: is the bottleneck the CMS or a misconfigured theme/plugin/cache?
3. URL map: planned 301 redirects; do not launch without equivalents.
4. Indexable content: same (or better) titles, H1, internal links, and schema.
5. Team: who publishes, who deploys, who responds if the site goes down?
6. 24-month budget: hosting, licenses, dev hours, periodic SEO audits.

Migrating WordPress → Next.js (or the reverse) for technical reputation alone, without a checklist, is one of the most expensive ways to lose stable traffic.

Common myths

“Google prefers Next.js”

Google prefers fast, clear, well-linked pages. The framework is invisible when HTML and technical signals are correct.

“WordPress is dead for SEO”

A large share of the web runs on WordPress and ranks fine. What fails is a bloated theme with no maintenance.

“With Next.js I do not need technical SEO”

You still need canonicals, sitemaps, redirects, structured data, and Search Console monitoring.

“Headless is always the perfect middle ground”

It adds complexity (two systems, APIs, content preview). It pays off when the frontend is the bottleneck, not the dashboard.

FAQ

Next.js or WordPress for an SEO-first blog?

For most small and mid-size teams, WordPress with a fast theme, solid SEO plugin, and editorial discipline gets results sooner. Next.js pays off when the blog is part of a larger web product or when performance is a proven competitive edge.

Can I improve SEO without leaving WordPress?

Yes: lighter theme, fewer plugins, cache, WebP images, CDN, fix broken links, improve content. Many sites “need Next.js” when they actually need technical cleanup.

How long until SEO impact after migrating to Next.js?

Weeks to months. Google must recrawl, process redirects, and re-evaluate signals. Plan a Search Console watch period — do not expect a jump on deploy day.

Do WooCommerce and Next.js together make sense?

Headless Woo setups exist but are advanced projects. For standard catalog SEO, Woo on classic WordPress remains the most predictable option.

Where does Veloce Devs fit in this decision?

We build performance-oriented sites with strong technical SEO — often combining familiar CMS workflows with modern frontends when the business case is clear. The main landing summarizes services and approach; you do not need to pick a stack before understanding your context.