Category: Technical SEO

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.

Google does not only measure keywords — it also cares about how fast and stable your site feels to visitors. That is where Core Web Vitals come in: three metrics that summarize loading, interactivity, and visual stability. If your site fails on mobile, you can lose rankings even when content is strong.

This guide explains what they mean, which thresholds Google uses, and what to measure first — without assuming you are a performance engineer.

Table of contents

• What Core Web Vitals are
• The three metrics: LCP, INP, and CLS
• Why they matter for SEO
• Thresholds: good, needs improvement, poor
• What to measure first (and where to look)
• Common causes of poor scores
• Quick checklist before asking for help
• Common myths
• FAQ

What Core Web Vitals are

Core Web Vitals (CWV) are a set of web performance metrics Google uses to evaluate page experience. They do not replace good content or sound technical foundations, but they can influence rankings when two pages compete for the same search intent.

Since 2021 they have been part of page experience signals. In practice, most teams track them because:

• They reflect what users experience on mobile — where most traffic happens.
• They can be measured with free tools (PageSpeed Insights, Search Console).
• Fixing them often improves conversions and bounce rate, not just SEO.

The three metrics: LCP, INP, and CLS

LCP — Largest Contentful Paint (loading)

Measures how long until the main content block appears: a hero, a large image, or a prominent headline. If visitors stare at a blank screen too long, LCP suffers. It is the most visible metric for people arriving from search.

INP — Interaction to Next Paint (responsiveness)

Largely replaced the older FID metric. It measures latency when users interact: clicking a button, opening a menu, submitting a form. A site that feels sluggish on tap often has high INP even when LCP looks fine.

CLS — Cumulative Layout Shift (visual stability)

Counts how much the layout jumps while loading: a banner pushing text, a font resizing, an ad shifting the buy button. It frustrates users and hurts perceived quality.

For priority order from a technical team perspective, see our guide on SEO for developers: what to measure first.

Why they matter for SEO

Google has repeated that helpful content comes first. Still, CWV act as a tiebreaker: between two relevant URLs, the faster and more stable one has an edge. Also:

• More efficient crawling: slow pages consume crawl budget; Google may index fewer URLs on your domain.
• Indirect CTR benefits: a smooth site retains users longer; positive engagement reinforces visibility over time.
• Mobile-first alignment: Google primarily indexes the mobile version; CWV are evaluated largely on real devices.

Speed optimization is not a Google hack — it aligns product, UX, and SEO. Well-built modern frontends (including headless setups done right) can make good CWV easier, but architecture alone fails if images weigh megabytes or the server responds slowly.

Thresholds: good, needs improvement, poor

Google publishes reference ranges (they can change; always check official docs). Practical summary:

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5 s	2.5 – 4.0 s	> 4.0 s
INP	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	≤ 0.1	0.1 – 0.25	> 0.25

Search Console groups URLs into Good, Needs improvement, and Poor based on field data (real Chrome users). PageSpeed Insights blends lab and field data — useful for diagnosis, but they do not always match perfectly.

What to measure first (and where to look)

1. Home and conversion landings — they usually get the most search traffic and clicks.
2. Product or service templates — one template issue affects hundreds of URLs.
3. Mobile version — prioritize mobile even if analytics show desktop converts more.

Common tools (without diving into setup):

• Google Search Console → Experience report → Core Web Vitals.
• PageSpeed Insights — single URL, recommendations per metric.
• Lighthouse in the browser — quick lab diagnosis (great during development).

For the full measurement toolkit, see our SEO DevTools guide for developers.

Once you understand the three metrics, move on to a practical PageSpeed audit: interpret PSI, compare lab and field data, and prioritize fixes. You can also test your URL with the PageSpeed simulator on our technical SEO landing.

Common causes of poor scores

High LCP

• Uncompressed hero images or oversized resolutions.
• Slow server or missing cache (high TTFB).
• Fonts or scripts blocking initial render.

High INP

• Heavy JavaScript on the main page.
• Third-party widgets (chat, analytics, maps) competing on the main thread.
• Forms or filters that recalculate too much on interaction.

High CLS

• Images or videos without reserved space (width/height).
• Banners or pop-ups inserting content above the fold.
• Web fonts that change text size when they load.

Most causes are cross-platform: whether you run classic WordPress, a headless CMS, or a modern framework — diagnosis starts with measuring and prioritizing.

Quick checklist before asking for help

1. Do you have the CWV report in Search Console without mass crawl errors?
2. Have you tested home and main landing in PageSpeed (mobile)?
3. Does the issue affect one URL or an entire template?
4. Do field data (real users) confirm what you see in the lab?
5. Have you noted what changed on the site before metrics worsened?

If you are still in the red after this, a prioritized technical SEO audit with an action plan for LCP, INP, and CLS beats a generic quick fix. For the step-by-step measurement workflow, see our practical PageSpeed audit guide.

Common myths

“A 100 Lighthouse score means top rankings”

Lighthouse is lab data. Google also uses field data. You can score 100 locally and still show Needs improvement in Search Console.

“Hosting alone fixes CWV”

Good hosting helps LCP, but images, scripts, and design matter equally. Upgrading plans without measuring is often expensive and ineffective.

“CWV only matter for e-commerce”

Any site competing in search benefits: blogs, B2B landings, corporate sites.

“A cache plugin fixes everything”

Cache mitigates TTFB and HTML but does not fix CLS from layout or INP from excessive JavaScript.

FAQ

How long until Core Web Vitals improve after optimization?

Field data in Search Console updates on roughly 28-day cycles. After deploying fixes, allow at least a month for a stable trend.

What is the difference between field and lab data?

Field: real users, varied networks and devices — what Google uses for ranking CWV. Lab: controlled simulation — great for debugging, not always representative of your audience.

Should I optimize desktop or mobile first?

Mobile. It is the primary reference for mobile-first indexing and where the worst LCP and INP often appear.

Do Core Web Vitals replace content?

No. A fast site with weak content does not rank. Secure indexing and relevance first; then tune CWV to win the tiebreaker.

More businesses hear the phrase headless WordPress with Next.js, but few explain what it actually means — and even fewer how it affects Google rankings. This guide gets straight to the point: clear concepts, real benefits, and when it is worth considering.

You do not need to be a developer to grasp the idea. You do need to know what to expect before investing in an architecture different from a traditional WordPress theme setup.

Table of contents

• What headless WordPress with Next.js means
• SEO and performance benefits
• When it makes sense (and when it does not)
• What to check before launch
• Common myths
• FAQ

What headless WordPress with Next.js means

In classic WordPress, the same system creates content and renders the site visitors see: you write a post in the dashboard and a PHP theme displays it.

In a headless approach, WordPress stays as the content hub: pages, blog posts, images, and copy live there. But the site users browse — and Google crawls — is built by another tool. In many modern projects, that layer is Next.js, a widely used framework for fast, scalable websites.

In short: headless WordPress with Next.js = content in WordPress + web experience in Next.js. They work together, each doing its job.

SEO and performance benefits

Google rewards useful, fast, technically sound sites. A well-executed headless project can help on three fronts:

1. Load speed

Generic WordPress themes often load scripts and styles every page does not need. A dedicated frontend can serve only what is required, improving metrics like LCP — one of the Core Web Vitals worth measuring first.

2. Control of public HTML

SEO depends on the HTML Google receives: titles, descriptions, internal links, structured data. Separating content from presentation lets you optimize that layer without disrupting the editorial workflow in WordPress.

3. Product scalability

If your site is not just a blog — service landings, interactive tools, client areas — Next.js fits better than a monolithic theme. More flexibility usually means better user experience, which also influences quality signals.

When it makes sense (and when it does not)

Scenario	Headless + Next.js?
Company site with blog and service landings	Yes, if you want performance and medium-term growth
Personal blog or small site with few yearly updates	Probably not — a solid WordPress theme is enough
Standard WooCommerce store with limited technical budget	Evaluate carefully — complexity increases
SEO and speed as a competitive edge	Yes — one of the most common reasons
Team with no developers and no maintenance agency	Not recommended — ongoing technical support is required

Headless is not a trend for its own sake: it is a bet on separating content from the web product. If you only publish occasional posts and never touch code, stay on classic WordPress. If you compete for Google rankings in demanding niches, it is worth exploring.

What to check before launch

Before calling a headless wordpress nextjs project done, validate the essentials — without diving into implementation details:

1. Mobile speed: test key pages with PageSpeed Insights or a simulator. Failing on mobile will hurt SEO.
2. Google indexing: check Search Console. Important URLs should crawl without mass errors.
3. Unique titles and descriptions: every page needs its own search snippet.
4. Internal links: blog, services, and contact should connect logically.
5. Editorial experience: the team writing content must publish in WordPress without friction.

To go deeper on measurement tools, see our SEO DevTools guide.

Common myths

“Headless is bad for SEO”

False. Google indexes the public site, not the WordPress dashboard. If that layer is fast, clear, and error-free, headless can rank as well as or better than a generic theme.

“WordPress becomes useless”

Not at all. It remains the content engine. What changes is who designs the building facade.

“Next.js is only for Silicon Valley developers”

It is widely used by agencies and digital products. What matters is having someone to maintain it.

“Moving to headless fixes SEO overnight”

Architecture helps, but content, authority, and ongoing monitoring remain essential.

FAQ

How much does a headless WordPress + Next.js project cost?

It depends on scope: number of templates, languages, integrations, and maintenance. It usually costs more than a premium theme, but less than rebuilding the site every two years because of performance issues.

Can I still edit content the same way?

In most setups, yes. WordPress remains the editing panel. What changes is how that content appears on the final site.

Does it work for multilingual SEO?

Yes, but it requires planning. Each version of a page must be clear for Google and users, without careless duplicate content.

How is this different from “Next.js vs classic WordPress for SEO”?

This post explains the combination of both. A direct comparison of approaches is covered in a dedicated blog article.

When developers think about SEO, they usually picture keywords and meta descriptions. But real rankings start earlier: at the server, in the code that generates HTML, and in the HTTP headers no one sees at a glance. SEO for developers is not about writing good copy—it is about building a technical foundation that does not block Google.

The problem is that there are dozens of possible metrics. This guide gives you the right order to measure what matters most first, without drowning in data.

Table of contents

• The technical SEO pyramid
• 1. Crawling: the first thing to measure
• 2. Correct indexing
• 3. Core Web Vitals
• 4. Mobile speed
• The 2026 measurement stack
• Integrating it into your workflow
• FAQ

The technical SEO pyramid

Most articles list metrics without hierarchy. But technical SEO has a layered logic: if the bottom layer fails, the ones above it do not matter.

1. Crawling — Can Googlebot reach the content?
2. Indexing — Does Google understand which URL is canonical and in which language?
3. Performance — Does it meet Core Web Vitals thresholds?
4. Content and authority — Does it answer better than the competition?

A developer can directly influence the first three layers. The fourth depends on the editorial team, but it also benefits from clean URL structure and solid internal linking—both engineering decisions.

1. Crawling: the first thing to measure

If Googlebot cannot crawl a page, it does not exist for the search engine. The most common crawl errors on sites with a modern frontend (React, Next.js) or decoupled CMS — for example a headless WordPress with Next.js project — are:

5xx errors

A server response (timeout, CMS API error, failed SSR) tells Google the page is unavailable. A few intermittent 5xx on secondary routes is tolerable; on the homepage or service landing pages it is critical. Monitor in Search Console → Coverage → Server error (5xx).

Redirect chains

A single 301 redirect is correct; three redirects in a chain (/contact → /contact/ → /en/contact/) waste crawl budget and can confuse PageRank attribution. Always point to the final destination in a single hop when possible.

Misconfigured robots.txt

An accidental Disallow: / in production blocks the entire site. Check https://yourdomain.com/robots.txt before every deploy. In Next.js (and other frameworks) you can define it in a version-controlled file in your repo.

JavaScript that blocks crawling

If critical content only exists in the DOM after JavaScript executes, Googlebot may not see it on the first crawl pass. Server Components in Next.js App Router eliminate this problem: HTML arrives complete in the first response.

2. Correct indexing

Googlebot reaching your page does not guarantee it indexes it correctly. There are three signals Google checks to decide which URL to index:

Canonical

The <link rel="canonical"> tells Google which is the definitive URL. On multilingual sites, each page needs its own canonical pointing to its locale version:

<!-- correct -->
<link rel="canonical" href="https://yourdomain.com/en/service/" />

<!-- wrong: points to CMS or admin subdomain -->
<link rel="canonical" href="https://cms.yourdomain.com/service/" />

Always validate in View Source of the public URL, not in React DevTools.

hreflang

On EN + ES sites, each page needs correct hreflang tags. A common mistake is pointing hreflang="en" to the same URL instead of the EN version:

<link rel="alternate" hreflang="en" href="https://yourdomain.com/en/service/" />
<link rel="alternate" hreflang="es" href="https://yourdomain.com/es/servicio/" />

If the CMS manages translations and the frontend consumes them via API, configure hreflang in the layer that generates public HTML (e.g. generateMetadata in Next.js).

Coherent sitemap

The sitemap should list only canonical, indexable URLs. A URL that appears in the sitemap but has noindex creates a contradictory signal that Google resolves at its own discretion. Generate the sitemap dynamically from the same data source as your routes.

3. Core Web Vitals

Google has used Core Web Vitals as a ranking signal since 2021. In 2026 the weight has increased for mobile searches. The three metrics to monitor:

Metric	What it measures	Green threshold
LCP (Largest Contentful Paint)	Time until the largest visual element is visible	< 2.5 s
INP (Interaction to Next Paint)	Response to user interactions (clicks, keyboard)	< 200 ms
CLS (Cumulative Layout Shift)	Visual stability: content should not shift while loading	< 0.1

Common causes of high LCP

• Hero image without priority in next/image: the browser downloads it too late.
• Render-blocking web fonts: use font-display: swap or load them with next/font.
• High TTFB from slow SSR: check slow CMS/API queries or missing cache or incremental regeneration.

Common causes of high CLS

• Images without explicit dimensions (width and height or aspect-ratio in CSS).
• Cookie banners that appear late and push content down.
• Web fonts that substitute the system font with different metrics.

4. Mobile speed: the most overlooked metric

PageSpeed Insights has two tabs: lab data (Lighthouse) and field data (CrUX). Field data is what Google uses for ranking. On new or low-traffic sites CrUX will be empty—trust lab data and Search Console in that case.

Always check in mobile mode with simulated 4G network, not just desktop. A site scoring 95 on desktop Lighthouse can score 60 on mobile due to unoptimized images or excessive JavaScript.

You can simulate this analysis directly in the Veloce Devs PageSpeed simulator without installing anything.

The 2026 measurement stack

These tools cover all four pyramid layers in most projects:

Tool	What it measures	Free
Google Search Console	Crawling, indexing, field CWV, sitemaps	Yes
PageSpeed Insights	Lab + field CWV, Lighthouse audit	Yes
Screaming Frog (free tier)	Bulk crawling, redirects, canonicals, meta tags	Yes (500 URLs)
curl / httpstatus	Redirect chains, HTTP headers, status codes	Yes
SEO suite / rank tracking	Keywords, rankings, recurring audits	Varies (e.g. Veloce Devs SEO services)

Integrating it into your workflow

Measuring once is not enough. Technical SEO is maintained by integrating checks into the development cycle:

Every pull request

• Does the change affect routes or slugs? → Add a redirect if an existing URL is removed.
• Are new images added? → Verify descriptive alt and WebP/AVIF format.
• New heavy JS component? → Check bundle impact with @next/bundle-analyzer.

Weekly

• Check Search Console: new 5xx, 404, or “Crawled – currently not indexed” pages.
• Review Core Web Vitals on main landing pages.

Monthly

• Audit with Screaming Frog or equivalent: redirect chains, duplicate titles, orphan pages.
• Compare GSC impressions and positions with the previous month.
• Review sitemap: does it include all new URLs and exclude noindex ones?

FAQ

Where do I start if the site is already in production with issues?

Start with Search Console: fix 5xx errors first (they affect crawling), then incorrect canonicals (they affect indexing), then out-of-range CWV (they affect ranking). In that order you get the greatest impact with the least effort.

Are Core Web Vitals the most important SEO factor?

No. They are a tiebreaker when content quality is similar. First make sure pages are correctly crawled and indexed; then optimize performance. A page with perfect LCP but no indexing does not rank.

Does Next.js App Router already handle SEO automatically?

It handles a lot: Server Components generate complete HTML, generateMetadata centralizes meta tags, and next/image optimizes formats. But it is still your responsibility to configure canonicals, hreflang, a coherent sitemap, and to avoid HTTP errors in production.

How long until technical fixes show impact?

It depends on the site’s crawl frequency. New or low-traffic domains can take 2 to 8 weeks. Use URL Inspection → Request indexing in Search Console to speed up key pages after each major fix.