Edge SEO: The Complete Guide to SEO at the CDN Level

Edge SEO is the practice of changing what search engines read on a page by rewriting or injecting on-page elements at the CDN edge, between the visitor and your origin server, instead of editing the CMS that generated the page. The crawler does not download the page your CMS produced; it downloads a transformed version assembled by code running a few milliseconds away. The technique does one job precisely: it fixes how search engines see the elements they are told to read, and it can do that in seconds, without a deploy and without touching your templates.

This is the complete guide: what edge SEO can change, how a Cloudflare Worker does it, what it costs in performance, when it is the right tool and when it cannot save you, and how it connects to the AI-era formats like llms.txt. If you want the short version first, our article What Edge SEO Is and Why Cloudflare Users Need It covers the mechanics in depth, and Edge SEO vs Traditional SEO compares the two approaches directly.

What “the edge” means, and where the idea came from

Every site on a CDN sits behind a network of caching servers. When a visitor requests a URL, the request goes to the nearest of those servers, and only on a cache miss does it travel on to your origin. That first stop is the edge. It was designed to be a pass-through; the fact that it can also be a place where code runs is what makes edge SEO possible.

Cloudflare made its edge programmable on 29 September 2017, when it announced Cloudflare Workers: Run JavaScript Service Workers at the Edge. The post is worth reading because it defines the whole field in one sentence: a Service Worker “intercepts web requests destined for your server before they hit the network, allowing you a chance to rewrite them, redirect them, or even respond directly.” The update at the top of that same page shows the follow-up date: 13 March 2018, “now available to everyone.” At launch Cloudflare described its network as an HTTP cache in 117 locations; today it runs in more than 330 cities and fronts sites that a rough estimate puts at one in five of the public web, figures covered in our what-is-edge-seo article.

An edge SEO worker is a small piece of software, written against an API close to the browser’s Service Worker standard, that runs on those CDN servers. It receives the request, fetches your real page from origin, rewrites the parts that matter for search, and hands the modified response to whoever asked for it. The origin never learns the change happened.

What you can change at the edge

Search engines are told, by convention, to read a small set of page elements. Most of those elements live in the page <head>, and all of them can be rewritten or injected by a worker. The table below is the practical map of the technique.

Element	What search engines use it for	What a worker can do
`<title>`	The blue result link; Google calls it “often the primary piece of information people use to decide which result to click” in its title link guidance	Replace it per URL or per pattern, or A/B test two versions
Meta description	The snippet under the link, and a factor in whether people click	Replace per URL or per section; the same A/B test applies
`rel="canonical"`	Tells Google which URL in a duplicate cluster is preferred, “a strong signal” per Google’s documentation that also consolidates links to the chosen URL	Add or rewrite per URL, or set as an HTTP header, which Google documents as an alternative
`hreflang`	Declares language and regional alternates of a page	Inject the alternate links for multilingual sites, as our SEO automation examples describe
JSON-LD structured data	The markup behind rich results; Google recommends JSON-LD and reports, for example, that Rotten Tomatoes measured a 25% higher click-through rate on 100,000 structured pages in its structured data introduction	Inject a `<script type="application/ld+json">` block on pages that have none
Open Graph and Twitter cards	The previews shown when a page is shared on social networks	Inject or correct the meta tags
HTTP headers	`Link` headers, `X-Robots-Tag`, and cache control	Set per response, which matters for cases like canonicals on non-HTML files
Redirects	Moving crawlers from one URL to another	Return a 301 for matching requests, and only for matching requests (see the cloaking warning below)

The important distinction is between elements and substance. Every row in that table is presentation: data about the page, not the page. What the edge cannot do is write more content, make a thin page deeper, or earn links. A great title on an empty page still ranks like an empty page. We will come back to that limit in the “not enough” section.

The seven practical Cloudflare Worker examples on this blog show working code for most of these rows, including the canonical and A/B-test cases.

How a Cloudflare Worker actually does it

A worker is a JavaScript (or TypeScript, Python, Rust) function deployed to Cloudflare’s network, with one entry point that runs on every request. The logic for SEO work has three parts.

Intercept. The worker receives the request before it reaches your origin. It can read the URL, the headers, and the user agent, and it decides whether this request is worth touching. The usual first check is the response’s Content-Type: if it is not HTML, the worker returns the response untouched. Images and APIs are never slowed by the rewrite.

Fetch and rewrite. The worker fetches your origin page. To edit the HTML it uses HTMLRewriter, which Cloudflare’s documentation describes as a “jQuery-like” experience that lets you build HTML parsers inside a worker. You attach handlers with CSS-style selectors, and the element handlers can do the useful work: setAttribute, removeAttribute, append, prepend, replace, remove. The constructor and handler shape are direct from the HTMLRewriter docs:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const res = await fetch(request);
    if (!(res.headers.get('Content-Type') || '').startsWith('text/html')) return res;

    const newTitle = titleFor(url); // your lookup table or rule
    if (!newTitle) return res;

    return new HTMLRewriter()
      .on('title', { element: (el) => el.replace(newTitle, { html: true }) })
      .on('link[rel="canonical"]', { element: (el) => el.setAttribute('href', canonicalFor(url)) })
      .transform(res);
  }
}

A laptop running a code editor, the kind of file a Cloudflare Worker script lives in — Credit: dkomov, Pexels License, via Pexels

Because handlers can be async, a rewrite can look up a title in a key-value store or an API before it writes the tag, which is how a per-URL title table works for 50,000 products without 50,000 template edits. Cloudflare’s explainer, Cloudflare Workers Explained, walks through what Workers are and how code at the edge differs from a traditional server:

Serve. The transformed response is returned. With Workers Caching it can itself be cached at the edge, so the rewrite runs only on a cache miss; the pricing page notes that CPU time is only incurred when the worker actually runs.

The one technique in this toolbox that needs a caution is user-agent conditional serving: giving Googlebot different HTML than a human gets. On its own, checking the user agent is how redirects and canonical fixes are targeted at crawlers. But Google’s spam policies define cloaking as presenting different content to users and search engines “with the intent to manipulate search rankings,” and their first example is “inserting text or keywords into a page only when the user agent that is requesting the page is a search engine.” The safe line is simple: rewrite elements that visitors also see (titles appear in browser tabs, descriptions in the results page), and never swap entire page content for crawlers. Edge SEO is a way to fix what everyone sees; it is not a permission slip to show Googlebot a different site.

Performance implications

A worker is code in the request path, so the honest question is what it costs. Three things keep the answer small. First, the code runs on the CDN itself, which is already the closest server to the visitor; Cloudflare positions Workers as a serverless platform on its global network in the official overview. Second, the budgets are documented: the free plan includes 100,000 requests per day with 10 milliseconds of CPU time per request, and the paid plan starts at $5 per month, numbers from the Workers pricing page. Rewriting the head of a normal HTML page is a small fraction of that per-request budget, and you stay inside it comfortably until you are rewriting very large pages across most of your traffic. Third, the rewritten response can be cached, so subsequent requests cost CPU only when the worker actually runs again.

The performance point cuts the other way too, which is why edge SEO is usually the faster option for the work it does: the change ships with the worker deployment, not with the next CMS release, and it never adds a plugin or a script tag to the page the visitor’s browser must download. For stores where time to first byte regularly sinks category pages, doing the SEO work outside the theme is a performance improvement in itself, a subject our edge SEO for e-commerce article covers.

When edge SEO is the right tool

The cases where the edge is the best answer all share one trait: the CMS is the wrong place to make the change, or the wrong place quickly.

No CMS access. A site on a locked-down platform, or a client who will not hand over credentials, is unreachable by normal means. The edge is in front of it and needs only the CDN.
Agencies managing many client sites. An agency changing titles across ten or fifty client domains cannot file a ticket per change. One pattern per client at the edge, and the retainers stop being bottlenecked on other teams’ deploy schedules. We wrote about the agency case in SEO for Agencies and the multi-domain version in Multi-Site SEO.
E-commerce theme lock-in. Shopify and similar platforms template every product page the same way, and editing theme code is risky and slow. An edge rewrite keyed to a per-URL table gives each product its own title and structured data without touching the theme.
Quick A/B testing of titles and descriptions. Testing which title lifts click-through is a natural edge job: serve variant A and variant B to a split of traffic, or roll variant B out and watch Search Console. Our click-through rate guide explains how to read the results honestly.
WordPress without a plugin. The same worker in front of WordPress fixes the five classic template problems without installing anything, as our edge SEO for WordPress piece shows.

Aleyda Solís has recorded the most accessible explainer of exactly these cases. Her Crawling Mondays session, Edge SEO: Implementing Technical SEO Changes via CDN, walks through how edge SEO works and when it makes sense to use it:

When edge SEO is not enough

Edge SEO changes how a page is presented to search engines. It does not change what the page says, who links to it, or whether it deserves to rank, and pretending otherwise is how sites waste a good technique.

Content gaps. If a page answers a query with three thin paragraphs, a better title tag changes which snippet appears, not the ranking of an insubstantial page. The content itself has to exist. Edge SEO can point engines at the right page, but it cannot make a page that does not answer the query.

Authority. Links and reputation are earned off the page, largely on other domains, and no amount of head rewriting manufactures them. Edge SEO changes what engines read about a page that already earned its place; it does not create the trust that gets a page there.

The cloaking line. Serving crawlers a different page than visitors, or keywords hidden from humans, is the one edge trick that turns into a penalty rather than a fix, per the spam policies quoted above. If a change is not something the visitor would accept seeing, it does not belong at the edge.

For these reasons edge SEO belongs on a site that has content worth ranking and a reason it cannot ship tags from the CMS quickly enough. On a site with nothing to say, it is polish on an empty house, and the strategy article on this blog makes the same point about when edge SEO is not enough.

llms.txt, AI answer engines, and the edge

The edge’s most interesting new job is serving the formats written for AI systems. The llms.txt proposal, first published in 2024 by Jeremy Howard, addresses a real mismatch: HTML pages are built for people, and converting them back into clean text is, in the specification’s own words, “difficult and imprecise.” The answer is a small Markdown file at /llms.txt that tells an agent what the site is and which pages are worth reading. Our llms.txt guide explains the format and its history in full.

The connection to edge SEO is structural. An llms.txt file is a resource like any other URL on your domain, so an edge worker can serve it from a KV store, keep it current without a deploy, and add the standard rel="describedby" and rel="alternate" link headers. That last part is notable because the specification explicitly says the header form “can be added in web server or CDN configuration without modifying any pages.” An edge in front of the site is exactly where that configuration lives.

The adoption numbers are now easy to check. The spec’s own page reports that thousands of sites publish an llms.txt file, that Chrome’s Lighthouse audits sites for one as part of its agentic browsing checks, and that OpenAI, Anthropic, and Gemini publish llms.txt files for their own developer documentation. Cloudflare’s Workers documentation does too: the top of the Workers overview tells an agent to fetch the documentation index at https://developers.cloudflare.com/workers/llms.txt before exploring further. In other words, one of the biggest CDN operators on earth runs the edge-SEO argument itself: the site your crawler or agent reads no longer has to be the HTML your CMS renders.

Two honest caveats. First, llms.txt is read by answer engines and coding agents, not by Google Search, which does not use it, as our llms.txt article notes. Second, the same spam policies that define cloaking also state they cover attempts to manipulate Google’s generative AI responses; an llms.txt file should summarize what the site genuinely is, not advertise a site that does not exist.

The worked example: SEOEdgeAI

SEOEdgeAI is the concrete product built around every idea above, and its product page and architecture page describe the pieces openly. At setup, it signs in with Google (which also connects Search Console) and deploys a single Cloudflare Worker in front of your site in about two seconds, with no code and no DNS change. The worker forwards requests to an edge proxy along with a site token. The proxy fetches your real page from origin, then injects the title, meta description, response headers, and JSON-LD structured data that an AI agent has decided on for that URL, live, and it never writes to your origin. Any path you configure as the blog is served directly by the hosted blog engine, which is how the articles appear on your own domain.

Two properties of the design are worth copying in any edge setup. The first is the fail-open path: if the proxy ever errors or times out, the worker sends the request straight to your origin, so your site never depends on the SEO layer being up. The second is the learning loop: the agent reads your Search Console numbers, forms a strategy, applies it through the proxy, then adjusts from the results, which is the difference between a rewriting tool and an agent. Full detail is on the how it works page and the product page, and the product’s feature list includes an llms.txt that “AI answer engines can read,” served the way this article describes.

Where to start

Begin with the smallest valuable rewrite, not the largest one. Take the five pages that already earn impressions but convert few to clicks, look up their titles and descriptions in Search Console, write better ones for the queries they already rank for, and put the changes at the edge. Watch the same reporting for two to four weeks before touching anything else. If a change moves clicks, keep it; if not, revert it in seconds, which is the whole advantage of doing the work in a place where deploys do not gate the turnaround. The edge SEO strategy guide on this blog lays out that plan, implement, measure loop step by step.

Edge SEO is a targeted technology with a clear boundary. It fixes the elements search engines are told to read, in seconds, without touching the CMS, and it has become essential for locked-down platforms, agencies, e-commerce themes, and now the AI formats served through the same edge. What it cannot do is create content or authority that is not there. Use it for what it is: the fastest honest way to change what search engines see about pages that already deserve to be seen.