{"id":105,"date":"2026-08-28T21:35:54","date_gmt":"2026-08-28T21:35:54","guid":{"rendered":"https:\/\/seoedgeai.com\/blog\/edge-seo-wordpress\/"},"modified":"2026-08-28T21:36:15","modified_gmt":"2026-08-28T21:36:15","slug":"edge-seo-wordpress","status":"publish","type":"post","link":"https:\/\/seoedgeai.com\/blog\/edge-seo-wordpress\/","title":{"rendered":"Edge SEO for WordPress: Fix Titles, Meta Descriptions and Structured Data Without a Plugin"},"content":{"rendered":"

WordPress is good at managing your content and bad at managing your <title><\/code> tags. The tag is assembled from parts (the page title, the site name, a page number), a theme template or an SEO plugin then stamps one site-wide format on all of it, and block themes hide the fields you would want to edit. Edge SEO removes that whole layer of pain. A Cloudflare Worker that sits in front of your WordPress site rewrites the <title><\/code>, the meta description, the canonical, the hreflang tags and the JSON-LD in the HTML as it passes through, per URL, with no theme edit and no plugin. WordPress keeps running exactly as it does today. The crawler just sees better metadata.<\/p>\n

Below: the pain points the edge removes, what a Worker actually rewrites, how the changes survive the CDN cache, a step-by-step setup, and how this blog does exactly that.<\/p>\n

What edge SEO means for a WordPress site<\/h2>\n

Edge SEO<\/a> is rewriting what search engines see on a page at the CDN edge, between the visitor and your origin server, instead of editing the CMS, the template or the code that produced the page. For a WordPress site on Cloudflare, the “edge” is a Cloudflare Worker<\/a>: a small program that runs on every request to your domain, fetches your WordPress site, and edits the HTML response on its way out. Nothing on your origin changes. Nothing in your theme’s header.php<\/code> or in the site editor changes. Publish a new post in WordPress normally, and the Worker applies the same rules to it automatically.<\/p>\n

WordPress is a big target for this. According to W3Techs<\/a> it now powers 40.7% of all websites (58.9% of sites whose CMS is known), the largest of any CMS. Most of those sites run on the default title plumbing that follows.<\/p>\n

The five WordPress SEO headaches the edge removes<\/h2>\n

1. Title templates that fit every page and match none.<\/strong> WordPress core assembles the document title from parts, filtered through the document_title_parts<\/code> hook: the page title, an optional page number on paginated views, the site name, and a tagline on the home page. Your theme or SEO plugin then wraps that in one template for every URL, so you get Post Name | Site Name<\/code> everywhere. That is fine for a blog and wrong for a business with different kinds of content. Making the convention vary per URL means editing template files or fighting a plugin’s title templates.<\/p>\n

2. Thin archive, tag and pagination titles.<\/strong> WordPress appends the page number itself on paginated views, and archives inherit the format Category: News | Site Name<\/code> or Croissants | Site Name<\/code>. On an ecommerce-flavored blog where tag pages can rank, that is a whole tier of URLs sent to Google with titles nobody would click.<\/p>\n

3. Block themes that hide the fields.<\/strong> Block themes arrived with WordPress 5.9, as the WordPress documentation<\/a> explains: every part of the site, including the header, is a block to be edited in the Site Editor. There is no SEO panel there, and no meta description field. The header template part decides what ends up in the <head><\/code> of every page, so a site editor who “hides the title” changes the visible heading, not the <title><\/code> tag the crawler reads. The edge fixes what the template emits.<\/p>\n

4. Two SEO plugins that fight each other.<\/strong> The usual answer to all of the above is an SEO plugin: Yoast SEO or Rank Math. They work, up to a point. But install two, or keep one half-enabled while a theme adds its own tags, and you get duplicate meta descriptions, duplicate Open Graph tags and two sets of JSON-LD in the same <head><\/code>, leaving search engines to pick a winner. Even one plugin is a big surface on a site you care about, and its schema is templated, not per-page.<\/p>\n

5. Category descriptions, multilingual hreflang and JSON-LD conflicts.<\/strong> WordPress stores a description per category, but whether that description reaches the HTML depends on the theme template, and it is not a meta description. Multilingual sites need hreflang<\/code> tags that are mutual (each language version lists itself and every other version, with fully qualified URLs and an x-default<\/code> catchall, per Google Search Central<\/a>); keep that in a plugin and it can quietly vanish on your next theme change. And WordPress core has no structured data settings, so valid, per-page JSON-LD comes down to whatever your plugins happen to output.<\/p>\n

None of these are reasons to abandon WordPress. They are reasons to stop solving them in the CMS.<\/p>\n

What a Worker actually rewrites, with before and after<\/h2>\n

The three tags that decide your click-through rate are the <title><\/code>, the meta description and the canonical, and all three are plain elements in <head><\/code>. A Worker rewrites them per URL, at the moment the page is served. The before and after on a typical WordPress blog:<\/p>\n

\n\n\n\n\n\n\n\n
URL<\/th>\nBefore (theme or plugin default)<\/th>\nAfter (edge rewrite)<\/th>\n<\/tr>\n<\/thead>\n
Single post \/blog\/making-croissants\/<\/code><\/td>\nMaking croissants \u2013 Example Blog<\/code><\/td>\nMaking Croissants: A Step-by-Step Recipe With Video<\/code><\/td>\n<\/tr>\n
Tag page \/tag\/butter\/<\/code><\/td>\nButter | Example Blog<\/code><\/td>\nButter: 9 Recipes That Start With Butter<\/code><\/td>\n<\/tr>\n
Category \/category\/news\/<\/code><\/td>\nCategory: News \u2013 Example Blog<\/code><\/td>\nNews: What's New at Example Blog<\/code><\/td>\n<\/tr>\n
Paginated \/blog\/page\/2\/<\/code><\/td>\nBlog \u2013 Page 2 \u2013 Example Blog<\/code><\/td>\nBlog (Page 2 of 9) \u2013 Example Blog<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n

What makes this practical is HTMLRewriter<\/a>, Cloudflare’s streaming HTML parser, which the docs describe as “a jQuery-like experience directly inside of your Workers application.” You select elements with CSS selectors and rewrite them as the response streams through. A minimal Worker that fixes titles and injects JSON-LD on blog posts looks like this:<\/p>\n

export default {\n  async fetch(request) {\n    const url = new URL(request.url);\n    const res = await fetch(request);\n    const type = res.headers.get("Content-Type") || "";\n    if (!type.startsWith("text\/html")) return res; \/\/ only touch pages\n\n    const m = url.pathname.match(\/^\\\/blog\\\/([a-z0-9-]+)\\\/?$\/);\n    if (!m) return res;\n\n    const slug = m[1];\n    const title = slug.charAt(0).toUpperCase() + slug.slice(1).replace(\/-\/g, " ") + " | Example Blog";\n\n    const ld = {\n      "@context": "https:\/\/schema.org",\n      "@type": "Article",\n      headline: slug.replace(\/-\/g, " "),\n    };\n\n    class TitleHandler { element(e) { e.setInnerContent(title); } }\n    class JsonLdHandler {\n      element(e) {\n        e.append(`<script type="application\/ld+json">${JSON.stringify(ld)}<\/script>`, { html: true });\n      }\n    }\n\n    return new HTMLRewriter()\n      .on("title", new TitleHandler())\n      .on("head", new JsonLdHandler())\n      .transform(res);\n  },\n};\n<\/code><\/pre>\n
Meta descriptions, canonicals and hreflang are the same pattern: setInnerContent<\/code> for the description, setAttribute(\"href\", ...)<\/code> for a canonical, and append<\/code> or replace<\/code> for link elements. Because the rules key off the URL path, each section of the site gets its own convention, and changing 50,000 titles is editing one script, not running a database migration.<\/p>\n
If you want to see the approach demonstrated before you wire anything, Chris Lever’s talk at brightonSEO in April 2025 walks through Worker-based SEO changes that need no developer work on the origin side.<\/p>\n