Nadia Mohamed
Technical SEO
SEO for Engineers: An Implementation-First Guide to Technical SEO & GEO
What is SEO for engineers?
SEO for engineers is technical SEO practised from inside the codebase rather than from a spreadsheet of recommendations. It treats crawlability, rendering, Core Web Vitals, and structured data as engineering problems with diffs, tests, and deploy steps — and it extends the same discipline into GEO (generative engine optimization), where the goal shifts from “rank in Google” to “get quoted by ChatGPT, Perplexity, and Google AI Overviews.”
I write code and I do SEO, and this guide is written from that seat. Most SEO advice aimed at developers stops at “work with your marketing team to implement the recommendations.” This series does the opposite: it assumes you are the one opening the pull request. Every section here is something you can ship — a render-strategy decision, a <head> change, a JSON-LD block, a fetchpriority attribute — not a ticket you hand off.
This is the pillar for a series of framework-specific guides (Astro, React, Next.js — each covered in the series below). The through-line across all of them is a single arc: from crawlable to citable. Once your JavaScript renders server-side and your schema validates, there is a further, less-charted step — making the page something a large language model will actually lift a sentence from and attribute to you. That last step is where technical SEO meets GEO, and it is the reason this hub exists.
TL;DR — Key takeaways
-
SEO for engineers is a build discipline, not a marketing hand-off. The highest-leverage SEO fixes on a modern site — render strategy, LCP, schema injection, canonical handling — live in the frontend codebase. The person who understands the render path is the person who should be fixing them.
-
First-hand implementation experience is the E-E-A-T moat. AI engines increasingly weigh source credibility by entity and demonstrated experience, not just domain authority. An engineer writing about the exact diff they shipped carries an experience signal that generic SEO content cannot fake.
-
The pipeline has four stages: crawlable → fast → understandable → citable. Each stage is a prerequisite for the next. Schema on a page a crawler can’t render is invisible; a citable answer buried under a 6-second LCP rarely gets surfaced.
-
AI crawlers do not execute JavaScript. GPTBot, OAI-SearchBot, ClaudeBot, and PerplexityBot fetch raw HTML and parse it as text. A client-rendered page can rank on Google (whose renderer eventually catches up) and still be completely blank to the models that power ChatGPT Search and Perplexity.
-
Core Web Vitals are concrete, testable thresholds. web.dev sets LCP under 2.5s, INP under 200ms, CLS under 0.1. Every one of those has a code-level fix, and this guide shows the diffs.
-
Getting cited is a structural property of the page, not a copywriting trick. Extractable answers, valid schema, and a clear entity behind the content are what move a page from “indexed” to “quoted.” Two data points anchor this: Ahrefs found 38% of Google AI Overview citations came from pages already ranking in the top 10, and ConvertMate’s 80M+ citation study measured a 67% lift in citation eligibility for content with valid schema.
Why engineers should own SEO now
For most of SEO’s history, the technical layer was thin enough that a non-engineer could manage it: set a title tag, write a meta description, avoid obvious crawl traps. That world is gone. The moment a site adopts a JavaScript framework — React, Vue, Svelte, or a meta-framework on top — the questions that decide whether it ranks become engineering questions. Does the initial HTML contain the body copy, or does it arrive after hydration? Which templates server-render and which ship a shell? Is the JSON-LD in the server response or injected in a useEffect? You cannot answer any of those from a content calendar. You answer them by reading the render path.
There is a second, sharper reason, and it is specific to 2026. AI search engines evaluate credibility partly through experience signals — evidence that the author has actually done the thing they are describing. ConvertMate’s citation analysis found that pages quoting recognised experts appeared in 41% of cited content. An engineer documenting the exact fetchpriority change that dropped their LCP from 4.1s to 2.2s is producing first-hand, verifiable, hard-to-fabricate content. That is the moat. It is also why this series is written in the first person about real diffs rather than as generic best-practice roundups — the format is the E-E-A-T strategy. The mechanics of turning that experience into a machine-readable entity signal are covered in the E-E-A-T and author-entity guide; here the point is simpler: the person with the commit history has the credibility, so the person with the commit history should be writing.
The arc: from crawlable to citable
Everything in this hub sequences into four stages. They are ordered because each one gates the next — there is no point tuning schema on a page a crawler renders as an empty <div>, and no point chasing citations on a page that takes six seconds to become interactive.
- Crawlable — the content exists in the HTML a bot receives, before any JavaScript runs.
- Fast — the page clears Core Web Vitals so it isn’t suppressed on mobile or abandoned before it renders.
- Understandable — structured data tells engines what the page is, and who stands behind it.
- Citable — the content is shaped so an LLM can extract a self-contained answer and attribute it to you.
The rest of this guide walks each stage with the actual code. The first three are classic technical SEO reframed for the person shipping it. The fourth is GEO, and it is where the arc pays off.
Stage 1 — Crawlable: make sure the bot sees your content
The single most expensive SEO mistake in a JavaScript codebase is rendering primary content on the client. Google’s own JavaScript SEO documentation describes a three-phase pipeline — crawl, render, index — where the initial HTML is crawled first and JavaScript rendering is deferred to a later pass once resources allow. Content that only appears after hydration can be indexed late, discounted, or missed. And AI crawlers don’t have a second pass at all: they read the raw HTML and stop.
I am deliberately not re-litigating the SSR/SSG/ISR/CSR trade-offs here — I wrote a full treatment of rendering strategies for headless architecture, including the per-template decision and the six-step rendering audit, and duplicating it would just dilute both pages. The framework-specific mechanics live in the spokes: Astro (islands, zero-JS-by-default), React (the SPA-shell trap and how to escape it), and Next.js (App Router server components and generateMetadata).
What I will give you here is the one check that settles the question in ten seconds, regardless of framework. Ask for the page as an AI crawler would, and read what actually comes back:
# What does an AI crawler see? It never runs your JS —
# so this raw HTML is the whole story for ChatGPT/Perplexity.
curl -sA "GPTBot" https://example.com/your-page | grep -i "<h1\|your key sentence"If your H1 and body copy are in that output, the page is crawlable by everyone — Googlebot’s first pass and every AI bot. If the response is a shell (<div id="root"></div> and a script tag), you have found the problem: the content is being assembled client-side and the class of bots that never execute JavaScript sees nothing. The fix is architectural — move that template’s primary content into the server render path — and it is exactly the decision the spoke guides walk through per framework.
The same gap shows up between what your browser renders and what Googlebot renders. The ground-truth tool is Search Console’s URL Inspection → Test Live URL → View Tested Page → HTML. That HTML is what Googlebot’s renderer produced. Diff it against your browser’s DOM; anything in the browser but missing from the rendered HTML is being added too late to be reliable.
/assets/screenshots/url-inspection-rendered-html.png Stage 2 — Fast: Core Web Vitals fixes, with the diffs
Core Web Vitals are a confirmed page-experience signal, and unlike most of SEO they are unambiguous engineering targets. The thresholds, from web.dev:
- Largest Contentful Paint (LCP) — under 2.5s. The time to render the largest above-the-fold element.
- Interaction to Next Paint (INP) — under 200ms. INP replaced First Input Delay in March 2024 as the responsiveness metric.
- Cumulative Layout Shift (CLS) — under 0.1. How much the layout jumps as it loads.
Each has a fix that lives in code. Here are the ones I reach for first.
LCP — stop the hero image from waiting in line. The most common LCP failure I see is a hero image that the browser discovers late, because it’s referenced deep in the component tree and competing with render-blocking CSS. Two attributes fix the majority of cases: preload the LCP resource and tell the browser it’s high priority.
<!-- Before: the hero is discovered late, LCP drags -->
<img src="/hero.avif" alt="…" />
<!-- After: preload it in <head>, and mark it high priority -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
<!-- …and on the element itself -->
<img src="/hero.avif" alt="…" fetchpriority="high" decoding="async" />Pair that with getting render-blocking CSS and non-critical JavaScript out of the critical path — defer your scripts, and inline only the CSS the first paint needs. In a component framework this often means auditing what your layout component drops into <head> on every route.
CLS — reserve the space before the asset arrives. Layout shift is almost always an element that loads without the browser knowing how much room to leave for it. Images and embeds are the usual culprits, and the fix is to always ship intrinsic dimensions:
<!-- Before: image loads, everything below it jumps down -->
<img src="/diagram.avif" alt="…" />
<!-- After: width/height let the browser reserve the box up front -->
<img src="/diagram.avif" alt="…" width="1200" height="675" />The same principle covers late-loading ads, embeds, and web fonts: give them a reserved box (aspect-ratio, min-height, or font-display: optional for fonts) so nothing reflows once they arrive.
INP — get off the main thread. INP regressions come from long JavaScript tasks blocking the main thread when the user interacts. The levers are shipping less JavaScript, deferring non-critical work, and breaking up long tasks so the browser can respond between chunks. In practice, the biggest single win is usually hydration cost: a framework that hydrates the entire page on load blocks interaction far longer than one that hydrates only the interactive islands — which is exactly why the framework choice in the Astro and React spokes has direct INP consequences.
Measure with field data, not lab scores. Lighthouse is diagnostic; what Google actually ranks on is the real-user data in the Chrome UX Report, surfaced through PageSpeed Insights and Search Console. A page can score well in a lab run on your fast laptop and still fail LCP for real mobile users on a mid-tier phone.
Stage 3 — Understandable: schema that validates
Once the content is crawlable and fast, structured data tells engines what the page is. In 2026 schema does double duty: it drives traditional rich results (where they still exist) and it is one of the strongest, most controllable inputs to AI citation eligibility. The ConvertMate analysis of 80M+ AI citations measured a 67% improvement in citation eligibility for content carrying valid schema — a bigger, more deterministic lever than almost anything on the content side.
The engineering requirement is specific and it is where implementations fail: the JSON-LD must be in the server-rendered HTML, not injected client-side. A <script type="application/ld+json"> that a useEffect appends after hydration is invisible to every AI crawler, because none of them execute JavaScript. It works for Googlebot (eventually) and fails for exactly the engines you’re adding schema to reach.
Here is the Article block I ship, with the detail that most generators get wrong — the author referenced as an entity by @id rather than duplicated inline, so the Person entity is defined once and pointed at everywhere:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Article title matching the H1",
"datePublished": "2026-06-20",
"dateModified": "2026-06-20",
"author": { "@id": "https://example.com/about/#person" },
"publisher": { "@id": "https://example.com/#organization" },
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/insights/your-slug/"
}
}
</script>The @id reference resolves against a Person node you define once (on your About page, in Organization/Person schema) with a populated sameAs array linking your external profiles. That single-source-of-truth pattern is what lets an AI engine connect a page to a consistent, verifiable entity — the full priority stack and the Person/sameAs mechanics are in the structured data for AI search guide.
In a framework, “in the server render path” has a concrete home. In Next.js it’s generateMetadata or a server component that renders the script tag; in Astro it belongs in the component frontmatter so it’s emitted at build time, e.g.:
---
// Article.astro — schema is built server-side and emitted as static HTML
const schema = {
"@context": "https://schema.org",
"@type": "Article",
headline: post.title,
datePublished: post.date.toISOString(),
author: { "@id": "https://example.com/about/#person" },
};
---
<script type="application/ld+json" set:html={JSON.stringify(schema)} />Then validate. Google’s Rich Results Test renders the page the way Googlebot does and confirms the schema parses; the Schema.org validator covers types Google no longer previews. Validate every new template before launch and re-validate after template changes — silent schema regressions from a refactor are one of the most common findings on any site that’s been live a year.
Stage 4 — Citable: from validated schema to a sentence ChatGPT will quote
This is the payoff, and it’s the part almost no engineering-SEO guide reaches. Being crawlable, fast, and understandable makes you eligible to be cited. It does not make you quotable. Getting an LLM to lift a sentence and attribute it to your domain is a structural property of how the content is written and marked up — and it’s the bridge from this technical hub to the site’s GEO pillar.
Three structural moves do most of the work, and all three are things an engineer controls:
1. Write self-contained, extractable answers. LLMs pull passages that stand alone. A sentence that only makes sense after three paragraphs of setup is hard to extract; a sentence that fully answers a specific question in isolation is easy. Structurally, that means leading a section with a direct, complete answer, then elaborating — the inverted-pyramid pattern — and using a clean, sequential heading hierarchy so each section is an addressable unit. The FAQ pattern at the bottom of every article in this series exists for exactly this reason: each question-and-answer pair is an independently extractable block.
2. Keep the entity behind the content unambiguous. AI engines increasingly evaluate credibility by entity — who is this, and have they demonstrated experience — rather than domain authority alone. The Person schema with a populated sameAs, consistent authorship across the cluster, and first-hand experience signals in the prose all compound here. This is the same reason the “why engineers should own SEO” argument earlier isn’t just positioning: the demonstrated experience is a machine-legible credibility signal, not only a human one.
3. Serve every one of those signals in raw HTML. Everything above is worthless to AI crawlers if it arrives via JavaScript. The extractable answer, the heading structure, the JSON-LD, the author entity — all of it has to be in the curl -A "GPTBot" output from Stage 1. This is why the arc is an arc and not a checklist: the citability stage depends entirely on the crawlability stage holding.
The practical, tactic-level version of this stage — freshness signals, expert attribution, the specific content edits — is in how to get cited by ChatGPT. What matters for the pillar is the shape of the claim: citability is downstream of the technical work, not a separate marketing exercise bolted on afterward. An engineer who ships stages 1–3 correctly has already done most of stage 4.
The guides in this series
This pillar is the map; the framework spokes are the territory. Each one takes the crawlable-to-citable arc and grounds it in one stack’s real APIs, defaults, and gotchas:
- Astro SEO — islands architecture and zero-JavaScript-by-default make Astro the strongest starting posture of the three, but content collections,
set:htmlschema injection, and view transitions each have SEO-specific handling worth getting right. - React SEO — the client-side-rendering shell is the default failure mode of a plain React SPA. This guide covers escaping it: when a meta-framework is the answer, and what to server-render when it isn’t.
- Next.js SEO — App Router server components,
generateMetadata, streaming, and ISR, with the specific patterns that keep primary content and schema in the initial HTML.
(These spokes publish across the weeks following this pillar — this hub links to them as the series rolls out.)
Where this fits in the bigger picture
SEO for engineers is one layer of a larger sequence. The technical SEO audit methodology is the standing-maintenance version of stages 1–3 — the crawl, index, Core Web Vitals, and schema checks run on a cadence rather than once. The 12-phase SEO & GEO audit framework sequences the technical layer alongside entity, content, and tracking work. If you’re generating large page sets from a template, programmatic SEO covers the failure mode where one template defect replicates across thousands of URLs — the exact scenario where owning the render path matters most.
If you’d rather have this designed and shipped end-to-end than build it internally, that’s what I do: full-stack development covers the build side — render strategy, Core Web Vitals, and schema deployed in the codebase — and GEO & technical SEO consulting covers the crawl, schema, and citation-readiness layers as a single scope. Either way, the arc is the same one this guide walks: get it crawlable, get it fast, get it understandable, and then get it citable.
FAQ
What is SEO for engineers?
SEO for engineers is technical SEO practised from inside the codebase rather than delivered as a list of recommendations to hand off. It treats crawlability, rendering strategy, Core Web Vitals, and structured data as engineering tasks with diffs and deploy steps, and extends the same discipline into GEO — optimising for citations in ChatGPT, Perplexity, and Google AI Overviews, not just rankings in Google.
How is SEO for engineers different from SEO for developers or regular SEO?
It’s the same discipline framed for the person writing the code. “SEO for developers” content often still assumes a marketing team implements the changes; an implementation-first approach assumes you are the one opening the pull request. The practical difference is depth: instead of “improve your Core Web Vitals,” it’s the specific fetchpriority and width/height diffs; instead of “add schema,” it’s where in the server render path the JSON-LD has to live so AI crawlers can see it.
Do AI crawlers like GPTBot and PerplexityBot execute JavaScript?
No. GPTBot, OAI-SearchBot, ClaudeBot, and PerplexityBot fetch the raw HTML and parse it as text without executing JavaScript. A page whose primary content, schema, or author signals are injected client-side is effectively blank to them — even if it ranks fine on Google, whose deferred rendering pass eventually processes the JavaScript. The fastest way to check is curl -A "GPTBot" <url> and confirm your H1, body copy, and JSON-LD are in the response.
What are the Core Web Vitals thresholds engineers need to hit?
Per web.dev: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1. INP replaced First Input Delay as the responsiveness metric in March 2024. Measure against real-user field data (Chrome UX Report, via PageSpeed Insights or Search Console), not just lab scores, because Google ranks on field data.
Why should engineers write the SEO content instead of marketers?
Because first-hand implementation experience is a credibility signal that AI engines reward and that generic content can’t fabricate. ConvertMate’s citation study found pages quoting recognised experts appeared in 41% of cited content, and AI engines increasingly weigh source credibility by entity and demonstrated experience. An engineer documenting the exact change they shipped produces verifiable, experience-backed content — the E-E-A-T moat that moves a page from indexed to cited.
What does “from crawlable to citable” mean?
It’s the four-stage arc this guide follows: make the content crawlable (present in the raw HTML before JavaScript runs), fast (clears Core Web Vitals), understandable (valid structured data with a clear author entity), and finally citable (shaped so an LLM can extract a self-contained answer and attribute it to your domain). Each stage gates the next — citability depends entirely on the earlier stages, because a citable answer injected via JavaScript is invisible to the AI crawlers you’re trying to reach.