Edge SEO as a “practice” has seen wide adoption since TechSEO Boost in November 2018, where I first used the term in relation to using CDNs and “workers” for the benefit of SEO.

Whilst we’re still, as an industry, establishing new internal processes for how we affect change and conduct transformations through the edge layer, as well as engaging in new conversations with developers around SEO like never before.

Until recently, Cloudflare have been at the forefront of the Edge SEO discussion due to being the only CDN offering a viable worker service, although a number of functions could be implemented through Lambda@Edge.

In my second article in this series, I explored Cloudflare alternatives for implementing redirects on the edge, including Lambda@Edge, Akamai Redirector Cloudlet, and via the AssignMessage Policy in Apigee.

Up until now there hasn’t been a comparable service to Cloudflare Workers (not counting ODN in this bracket), however Akamai are currently launching Edge Workers which has just launched its BETA.

At BrightonSEO I showcased alternatives to Cloudflare Workers and their capabilities:

Cloudflare workers

However, since BrightonSEO, Fastly have reached out with further information about Fastly’s edge capabilities in enacting change for SEO purposes:

Seeing your mystery box for us in your chart, I realized we perhaps haven’t been clear on our capabilities, so I wanted to confirm that we do indeed support each of those categories through our tech. – Sara Lasseter, Fastly Communications Manager

So, this may not be as “mystery box” as we’re led to believe.

Fastly’s Edge Solution

Fastly’s have recently published an article looking at how their edge solution can help webmasters optimize their sites for SEO.

Whilst the understanding of SEO and what influences rankings within Google might be a bit off in the article, Fastly does offer speed optimization benefits including gzip and Brotli compression, an image optimization feature, redirect management, and the ability to use server-timing to monitor and optimize critical path cacheability.

Aside from their communications, there isn’t any documentation to officially state Fastly’s ability to modify either the request or response and transform it for the purposes of search engine optimization.

Akamai EdgeWorkers

Release 1.0 of went live on October 15, 2019, with the first phase of their development roadmap able to support a number of edge SEO features.

Following conversations I’ve had Product Managers on the Akamai EdgeWorkers team, a scheduled release in the New Year will support caching and everything that impacts (i.e. changing the URL, origin path, or the origin).

With the release following that supporting body read/write and remote calls… And with that, being able to support the greater majority of edge SEO use cases out there.

Non-CDN Alternatives

Whilst not strictly CDNs, platforms such as ODN can be used to modify on-page content, internal linking, and URL level meta titles & descriptions.

A use case of this on OTA websites using third-party data feeds. In your title tag, you want to include the lowest price you can offer to entice traffic – however, given it’s a third-party data feed it’s likely that the price will be volatile – so manually maintaining this would soon obliterate the effort v reward benefits.

This can however be automated via a < script> injected by ODN:

 

<script>
$(window).on(“load”, function(){
document.title=”Best Price Insurance from Only” + document.getElementsByClassName(“dealprice”)[0].innerText +” | Insurance Co.”
});
</script>

In the source code, your your <title> element doesn’t change, but the script modifies the response, so Google displays a title tag along the lines of:

Best Price Insurance from Only £__ | Insurance Co.

With the “£__” being the lowest price value available from the third-party data feed.

Dan’s Taylor Edge SEO series

Part 1: Resolving SEO issues on legacy (and modern) platforms through edge SEO
Part 2: Creating & Managing Redirects on The Edge
Part 3: Integrating edge SEO into internal policies and workflows
Part 4: Alternatives to Cloudflare Workers