Edge SEO with Cloudflare Workers

There is a layer of the internet stack that sits between your server and every request that reaches your site. It is called the edge — where CDNs live, where SSL terminates, where DDoS protection happens. For the past five years, it is where the most sophisticated SEO practitioners have been doing things that are literally impossible at the origin server level.

Edge SEO is the most under-discussed technique in search engine optimization. Not because it is secret — Cloudflare Workers documentation is public, the code examples are everywhere — but because it requires a mental model shift. SEO practitioners think in terms of pages, content, and links. Edge SEO thinks in terms of HTTP requests and responses, interception and transformation, dynamic injection without origin modification.

Your static site generates HTML at build time. It is frozen. Every user, every crawler, every request gets the same HTML. That immutability is the whole point of static sites — speed through simplicity.

Edge SEO breaks that constraint without sacrificing the performance benefit. A Cloudflare Worker intercepts the response after it leaves your CDN but before it reaches the requester. In that interception window — measured in single-digit milliseconds — you can rewrite the HTML. And the free tier gives you 100,000 requests per day to do it.

How Cloudflare Workers Work

A Worker is a JavaScript function that runs on Cloudflare's edge network — over 300 data centers globally. When a request hits your domain (which uses Cloudflare DNS), the Worker executes before the response is delivered.

The basic structure:

export default {
  async fetch(request, env) {
    // Fetch the original response from your CDN
    const response = await fetch(request);

    // Only transform HTML pages
    const contentType = response.headers.get('content-type') || '';
    if (!contentType.includes('text/html')) {
      return response;
    }

    // Read the HTML
    let html = await response.text();

    // Transform it (this is where the magic happens)
    html = transformHTML(html);

    // Return the modified response
    return new Response(html, {
      status: response.status,
      headers: response.headers
    });
  }
};

That is the shell. Everything interesting happens in the transformHTML step. Let us build real implementations.

Use Case 1: Dynamic Schema Injection

Schema markup (JSON-LD) tells search engines what your page is about in structured data format. Normally, you inject it at build time. But if you need to update schema — new author bio, new organization description, new FAQ data — you must rebuild and redeploy the entire site.

Edge-side schema injection separates your schema data from your HTML entirely. Your static site stays clean. Your schema lives in Workers KV (Cloudflare's edge key-value store), and the Worker injects it per-request.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const response = await fetch(request);
    const contentType = response.headers.get('content-type') || '';

    if (!contentType.includes('text/html')) return response;

    // Look up schema data for this URL path
    const schemaData = await env.SCHEMA_KV.get(url.pathname, { type: 'json' });

    if (!schemaData) return response;

    // Build the JSON-LD script tag
    const schemaTag = `<script type="application/ld+json">${JSON.stringify(schemaData)}</script>`;

    // Inject before </head>
    let html = await response.text();
    html = html.replace('</head>', `${schemaTag}\n</head>`);

    return new Response(html, {
      status: response.status,
      headers: response.headers
    });
  }
};

The benefit: you can update schema for any page on any site by writing to KV, without triggering a rebuild. Schema updates propagate globally in under 60 seconds.

Use Case 2: Hreflang from One Codebase

If your network includes sites that target different regions or languages for the same topic, hreflang tags tell search engines which version to show to which audience. Traditionally, you hard-code these into your templates. But with a monoclone architecture, you might not know all the language variants at build time, or the relationships might change as you add sites.

A Worker can inject hreflang tags dynamically:

// Hreflang mapping stored in KV
// Key: "/best-pressure-washer/"
// Value: [
//   {"lang": "en-us", "url": "https://bestpressurewashers.com/best-pressure-washer/"},
//   {"lang": "en-gb", "url": "https://pressurewasheruk.co.uk/best-pressure-washer/"},
//   {"lang": "de", "url": "https://hochdruckreiniger.de/bester-hochdruckreiniger/"}
// ]

const hreflangData = await env.HREFLANG_KV.get(url.pathname, { type: 'json' });

if (hreflangData) {
  const tags = hreflangData
    .map(h => `<link rel="alternate" hreflang="${h.lang}" href="${h.url}" />`)
    .join('\n');
  html = html.replace('</head>', `${tags}\n</head>`);
}

Add or remove language variants by updating KV. No rebuild required.

Use Case 3: A/B Testing Titles

Title tags are the single most impactful on-page SEO element. But you never know which title formulation will perform best until you test it. Traditional A/B testing for titles requires either JavaScript (which Googlebot may not execute consistently) or server-side logic (which static sites do not have).

A Worker solves this cleanly:

// A/B test configuration in KV
// Key: "/best-electric-pressure-washer/"
// Value: {
//   "variants": [
//     "Best Electric Pressure Washers (2026) | Top 7 Tested",
//     "7 Best Electric Pressure Washers We Actually Tested | 2026"
//   ],
//   "split": 50
// }

const testConfig = await env.ABTESTS_KV.get(url.pathname, { type: 'json' });

if (testConfig) {
  const variant = Math.random() * 100 < testConfig.split ? 0 : 1;
  const newTitle = testConfig.variants[variant];
  html = html.replace(/<title>.*?<\/title>/, `<title>${newTitle}</title>`);

  // Also update the og:title meta tag
  html = html.replace(
    /(<meta property="og:title" content=").*?(")/,
    `$1${newTitle}$2`
  );
}

This serves different title variants to different visitors (and to Googlebot on different crawls), letting you measure which title formulation drives higher click-through rates in Search Console.

Use Case 4: Redirect Management at Scale

Managing redirects across sixteen sites using hosting provider configuration files (_redirects on Netlify, vercel.json on Vercel) is tedious and requires redeployment for every change.

A Worker handles redirects at the edge before the request even reaches your origin:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Check for redirect
    const redirectTarget = await env.REDIRECTS_KV.get(url.pathname);
    if (redirectTarget) {
      return Response.redirect(redirectTarget, 301);
    }

    // No redirect, serve normally
    return fetch(request);
  }
};

Adding, modifying, or removing redirects is a KV write operation. Changes propagate globally in seconds. No rebuild, no redeploy, no configuration file to maintain.

The Free Tier Math

Cloudflare Workers' free tier provides 100,000 requests per day. For a sixteen-site network, that is approximately 6,250 requests per site per day.

To put that in perspective: a niche site generating 200 organic visits per day (a reasonable number for a site in its first three to six months) serves roughly 600-1,000 total requests when you include page navigations and asset requests. But Workers only execute on routes you configure — if you only attach the Worker to HTML pages (not images, CSS, or JavaScript), the request count drops to roughly 200-400 per day per site.

At 400 requests per site per day across sixteen sites, you are at 6,400 daily requests. Comfortably within the free 100,000 limit.

Even as traffic grows, the paid tier is $5/month for 10 million requests. That is not a cost concern.

What Makes This Under-Discussed

The SEO industry is split into two cultures that rarely overlap. Technical SEOs understand crawling, indexing, and rendering but typically work within CMS platforms and do not think at the HTTP layer. Web developers understand Workers, edge compute, and request interception but do not think in terms of SEO signals.

Edge SEO sits in the gap between those cultures. It requires knowing which HTML modifications affect search engine behavior (schema injection, hreflang, title tags, canonical tags, meta robots) and knowing how to intercept and modify HTTP responses at the edge.

That combination is rare, which is why the technique remains under-discussed despite being publicly documented. There is no secret. There is only a skill gap.

Practical Considerations

Caching: Workers execute on every request by default. If your transformations are deterministic (same input URL always produces the same output), set appropriate cache headers so the transformed response gets cached at the edge. This reduces Worker invocations and improves performance.

Testing: Use wrangler dev to run Workers locally. Test every transformation against both a browser and a Googlebot user agent to ensure the modifications render correctly for crawlers.

Monitoring: Cloudflare's dashboard shows Worker invocation counts, CPU time, and error rates. Monitor these after deployment. A misconfigured Worker that throws errors on every request will degrade your site's availability.

SEO safety: Never cloak — do not serve different content to Googlebot than to users. Edge SEO transforms should apply equally to all requesters. Google's guidelines explicitly prohibit cloaking, and a Worker that checks the user agent to serve different content is a fast path to a manual action.

The Full Implementation

This post covers four use cases. The complete Edge SEO playbook — including fourteen Worker recipes, the KV data structure for managing transformations across sixteen sites, the deployment pipeline for Workers, and the monitoring dashboard — is in The $100 Network by J.A. Watte. Chapter 23 covers Edge SEO end to end, and Appendix O provides the full Worker recipe collection ready to deploy.

The edge is programmable. Your SEO should be too.

The SEO foundations for these techniques are covered in The $20 Agency, Chapters 3-5. This article builds on those basics with advanced multi-site strategies from The $100 Network.