Edge SEO: making SEO changes at the CDN, what it is good for, and the rules Google applies

Edge SEO means making SEO changes in the content delivery network (CDN) that sits in front of your website, instead of in the website's own code. A small script runs on the CDN's servers, reads each request and each response as it passes through, and changes it on the way out: a redirect, a title tag, an hreflang header, a robots rule, a block of structured data. The visitor and the search engine both receive the changed page, and the origin server never knows. It is the fix for a site whose platform or release queue will not let you make the change any other way.

How edge SEO works, step by step

When someone asks for a page on a site behind a CDN, the request reaches the CDN first. The CDN either serves a cached copy or fetches the page from your origin server, then sends it on. Modern CDNs let you run your own code at that point. The main options are Cloudflare Workers, Akamai EdgeWorkers, Fastly Compute and Amazon CloudFront with Lambda@Edge. Each one lets a function see the request before it reaches the origin and the response before it reaches the user.

That gives you two places to act:

• On the request. Decide before the origin is asked. This is where redirects live: if the path matches an old URL, answer with a 301 straight away and the origin never sees the request.
• On the response. Change what the origin sent. Add or rewrite HTTP headers, or rewrite the HTML itself. Cloudflare documents an HTMLRewriter class for exactly this, a streaming parser that lets a Worker find elements by CSS selector and change them as the page passes through. Akamai's EdgeWorkers documentation lists an html-rewriter for the same job.

What teams use edge SEO for

Change	Where it happens	Why the edge helps
Redirect maps after a migration	Request	Thousands of rules in one file, changed in minutes, no platform plugin
hreflang for international sites	Response header	Google accepts hreflang in HTML, in HTTP headers or in a sitemap, and treats the three as equivalent
X-Robots-Tag noindex on thin or filtered pages	Response header	Works on PDFs and other files that have no HTML head
Title and meta description fixes	Response HTML	Fixes a template the CMS will not let you edit
Structured data (JSON-LD)	Response HTML	Adds markup without a theme release
robots.txt and sitemap files	Request	Serve a file the platform controls badly or not at all
Canonical tags	Response HTML	Corrects a platform that points canonicals at the wrong URL

The common thread is speed of release. On many sites an SEO ticket waits weeks for a development sprint, and some hosted platforms do not expose the file at all. A rule at the edge ships the same day and can be switched off the same day.

A small example

This Cloudflare Worker passes every request through to the origin, then rewrites the title on one path and adds an hreflang header. It is a sketch of the pattern, not production code:

export default { async fetch(request) { const url = new URL(request.url); const response = await fetch(request); if (url.pathname !== "/pricing") return response; const changed = new Response(response.body, response); changed.headers.append( "Link", '<https://example.com/fr/pricing>; rel="alternate"; hreflang="fr"' ); return new HTMLRewriter() .on("title", { element(el) { el.setInnerContent("Pricing and plans | Example"); } }) .transform(changed); }
};

Two habits make code like this safe. Check the content type before you rewrite HTML, so you do not try to parse an image. And keep every rule in version control with a note on why it exists, because a change that lives only at the edge is invisible to anyone reading the site's own code.

The rules Google applies to changes at the edge

Google does not care where a change is made. It judges what it receives. Three parts of its own documentation matter most here.

Serve the same page to people and to Googlebot

Google's spam policies define cloaking as presenting different content to users and search engines with the intent to manipulate rankings and mislead users. An edge function can see the user agent, so it is easy to build a rule that treats Googlebot differently. Do not. Every change in this article should apply to every visitor. If you need to confirm that a request really came from Google, Google documents a reverse DNS lookup on the requesting IP address for that purpose.

Prerendering for bots is a workaround

Some teams use the edge to send a pre-rendered HTML copy to crawlers while users get the JavaScript app. Google calls this dynamic rendering, says it does not generally treat it as cloaking, and also says it is a workaround and not a recommended solution. Its recommendation is server-side rendering, static rendering or hydration. Use edge prerendering as a bridge while the real fix is built, and plan its end date.

Redirects and tests follow the normal rules

A redirect returned by an edge function is a server-side redirect as far as Google can tell, which is the kind Google says it interprets most reliably. Use a 301 or 308 when the move is permanent. For A/B tests that send users to a variant URL, Google's testing guidance asks for a 302, a rel="canonical" on the variants pointing at the original, and no special treatment of Googlebot.

The risks, and how to manage each one

• Two sources of truth. The CMS says one title, the edge serves another. Keep a written register of every edge rule, and review it whenever the site is redesigned.
• Caching. A rewritten response can be cached. Test a change with the cache bypassed, then purge the affected URLs after release.
• Silent failure. If a selector stops matching after a template change, the rewrite just stops happening. Crawl the affected pages after every site release and compare the served HTML with what you expect.
• Speed. Each function adds work to every request it runs on. Scope rules to the paths that need them rather than running them site-wide.
• Ownership. The CDN account usually belongs to engineering or security. Agree who can deploy edge code, and how it is reviewed, before the first rule ships.

When edge SEO is the right tool, and when it is not

Use it when the fix is clear, the platform blocks it, and the business cannot wait: a migration with a broken redirect map, a hosted store that will not expose hreflang, a legacy template nobody can safely touch. Use it for fast testing of a change you later move into the codebase.

Do not use it to hide a problem permanently. If the site's templates are wrong, the edge rule is a bandage, and the lasting fix belongs in the source. Before reaching for an edge rule, run the basics in our technical SEO checklist, because many issues have a simpler answer in the CMS settings. If nobody in house can write and review Worker code, a technical SEO specialist who has shipped edge rules before is worth bringing in for the first project.

Questions about edge SEO

Is edge SEO the same as technical SEO?

It is one way of doing technical SEO. Technical SEO is the work itself, such as redirects, indexing rules and markup. Edge SEO is a delivery method: making those changes in the CDN instead of the site's code.

Do I need Cloudflare to do edge SEO?

No. You need a CDN that runs your own code. Cloudflare Workers, Akamai EdgeWorkers, Fastly Compute and CloudFront with Lambda@Edge all do this. Pick the one your site already sits behind.

Can Google see changes made at the edge?

Yes. Googlebot requests the page like any visitor, the request passes through the CDN, and it receives the changed response. Use the URL Inspection tool in Search Console to confirm what Google fetched.

Is edge SEO cloaking?

Not when every visitor gets the same change. It becomes cloaking when the rule serves search engines different content from people with the intent to mislead.

Will edge SEO slow my site down?

A well-scoped rule adds very little. Run functions only on the paths that need them, and measure response times before and after release.

What an assistant reads when it reaches your page

Edge rules decide what every fetcher receives, and the fetchers now include the crawlers behind ChatGPT, Gemini, Perplexity and Claude. Those assistants describe a business from what they can read, so a title, a schema block or a robots rule set at the edge shapes their answer as much as Google's. It is worth asking an assistant what it says about your company after a big edge release and checking that the facts it repeats are the ones you shipped. That check, run across the main assistants, is the job AI Knows Us was built for.