Author: admin

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 in Next.js and headless WordPress projects:

5xx errors

A server response (timeout, GraphQL 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 you can define it in src/app/robots.ts with strict typing.

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 Next.js sites, each page needs its own canonical pointing to its locale version:

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

<!-- wrong: points to the headless CMS -->
<link rel="canonical" href="https://api.velocedevs.com/seo/" />

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://velocedevs.com/en/seo/" />
<link rel="alternate" hreflang="es" href="https://velocedevs.com/es/seo/" />

If Polylang pairs are correctly linked in WordPress and Next.js reads translations via WPGraphQL, this is generated automatically in generateMetadata.

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 GraphQL queries or missing ISR (revalidate).

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 are the tools we use at Veloce Devs to cover all four pyramid layers:

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
OpenSEO	Keywords, rankings, automated recurring audits	Via Veloce SEO Suite

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.

If you ship code, SEO is not something you can fully outsource to marketing. Most ranking failures start in engineering: JavaScript that blocks crawling, broken canonical tags, Core Web Vitals out of range, or sitemaps that do not match your real URL architecture. SEO devtools exist to bridge that gap between development and organic visibility.

This guide covers the stack we use at Veloce Devs on Next.js, headless WordPress, and WooCommerce projects—from the browser to CI/CD—with official resources and a workflow you can apply in your repo today.

Table of contents

• Why SEO is a developer responsibility
• Browser DevTools (Chrome and Edge)
• Lighthouse and PageSpeed Insights
• Google Search Console
• Crawling, logs, and CLI
• Recommended stack for headless projects
• Pre-deploy checklist for devs
• FAQ

Why SEO is a developer responsibility

Google does not index marketing promises—it indexes served HTML, HTTP responses, internal links, and performance signals. When a site takes more than three seconds on mobile or returns 5xx on locale-less routes, the damage happens before anyone writes a meta description.

High-performing teams usually share one pattern: developers validate technical SEO on every pull request, while marketing focuses on search intent and content. You do not need to become an SEO consultant; you need to know what to measure and where to look.

Browser DevTools (Chrome and Edge)

Chrome DevTools (and Edge equivalents) are the first line of defense. These tabs matter most in audits:

1. Lighthouse

Generates performance, accessibility, best practices, and basic SEO scores for the loaded URL. Use incognito mode with extensions disabled to avoid false positives.

2. Network

Filter by Doc, JS, and CSS. Look for:

• Render-blocking resources (missing critical CSS, synchronous JS in <head>).
• 404 responses or redirect chains (301 → 301 → 200).
• High TTFB on HTML documents (server, cache, or slow SSR).

3. Coverage

Shows how much downloaded JS/CSS is unused on the current view—ideal for spotting bloated bundles on lightweight landing pages.

4. Elements + meta tag search

With Ctrl+F inside Elements, verify in served HTML:

• One <title> and one <meta name="description"> per page.
• <link rel="canonical"> pointing to the canonical URL (no duplicate www if apex is policy).
• Consistent hreflang on multilingual sites (en, es, x-default when applicable).
• Accidental noindex in production.

Lighthouse and PageSpeed Insights

Local Lighthouse measures the current session; PageSpeed Insights adds field data (CrUX) when available. For new sites with no traffic, CrUX will be empty—trust lab data and Search Console.

On our technical SEO landing page, you can test your domain with a built-in PageSpeed simulator. Red scores usually mean LCP issues (hero image without priority, blocking fonts) or INP issues (too much JavaScript on the main thread).

Target benchmarks:

• LCP < 2.5 s
• INP < 200 ms
• CLS < 0.1
• Lighthouse SEO score ≥ 90 on main templates

Google Search Console

Search Console is the source of truth for how Google sees your site. As a developer, review weekly:

• Pages → Indexing: 5xx, 404, “Crawled – currently not indexed”, and unnecessary redirects.
• Sitemaps: submit https://yourdomain.com/sitemap.xml and confirm canonical URLs match the sitemap.
• Core Web Vitals: red/amber URLs that need code changes, not copy tweaks.
• URL Inspection: test a freshly deployed URL and request indexing after fixing canonicals or hreflang.

Crawling, logs, and CLI

When the site grows, the browser does not scale. Add CLI tools to the workflow:

Tool	Purpose
curl -I URL	Check HTTP status, Location, cache headers, and redirects.
Screaming Frog (free tier)	Crawl broken links, duplicate titles, empty meta tags, and click depth.
npx lighthouse URL --view	Repeatable audits in CI or local scripts.
Schema validators	Test JSON-LD (Organization, FAQPage, BlogPosting) before publish.

Running Lighthouse in GitHub Actions or your Hostinger/Vercel pipeline prevents regressions when someone adds a third-party script “just to test.”

Recommended stack for headless projects (Next.js + WordPress)

In headless architectures, SEO is split like this:

• Next.js (frontend): generateMetadata, sitemap, robots.txt, semantic HTML, ISR/SSR.
• WordPress (CMS): content, Yoast, Polylang, ACF fields exposed to WPGraphQL.
• Cloudflare / CDN: HTTPS, compression, cache rules without breaking dynamic HTML.
• SEO panel (keywords + rankings): so you are not relying on spreadsheets when URL count grows.

For keyword research, rank tracking, and recurring audits we use OpenSEO, available through our Veloce SEO Suite section. It complements Lighthouse (point-in-time performance) with continuous SERP data.

Pre-deploy checklist for developers

Add this list to your PR template or repo wiki:

1. Are canonical and hreflang present in served HTML (View Source, not only React devtools)?
2. Does the sitemap include only indexable URLs (no drafts, no noindex)?
3. One H1 per view and logical H2/H3 hierarchy?
4. Images with descriptive alt and modern formats (WebP/AVIF)?
5. Mobile Lighthouse ≥ 90 for performance and SEO on affected templates?
6. 301 redirects for legacy URLs and locale-less routes?
7. Search Console free of new 5xx or 404 errors after deploy?
8. Structured data validated with no critical errors?

Prefer a full-stack review? Request a technical SEO audit with a prioritized roadmap.

FAQ

Is Lighthouse enough for SEO?

No. Lighthouse covers basic technical signals and performance, but it does not replace Search Console (real indexing), keyword analysis, or large-scale internal link audits.

What is “dev SEO” in practice?

Applying technical SEO inside the development cycle: metadata in server components, clean URLs, performance, schema, and post-deploy monitoring—instead of patching issues after launch.

Should I use SEO plugins on headless WordPress?

Yes on the CMS (Yoast + WPGraphQL SEO) so the frontend consumes titles and descriptions, but Next.js generates the public HTML—always validate the live output.

How long until Google indexes technical fixes?

From hours to several weeks depending on authority and crawl budget. After fixing canonicals or sitemap, use URL Inspection in Search Console to speed up key pages.