Two weeks ago, our interview with Dan Taylor on Edge SEO went viral. As a result, you sent us a lot of your queries and concerns about Edge SEO, which we'd like to address in this blog article.
Edge SEO in brief
Short recap: Edge SEO enables you to make changes to your website without touching its actual codebase. These changes are made on a CDN's edge server.
Edge SEO introduces huge opportunities, as it provides you with a way to implement SEO recommendations even when there's a code freeze, for example. This is great, because it's essential to maintain your SEO momentum. Not just for your SEO performance, but also from an organizational point of view: you need to maintain momentum in order for people within your organization to keep believing in SEO (especially at the start of a new SEO campaign). Edge SEO enables you to do that, and that's great.
But Edge SEO isn't without its risks.
Edge SEO = Hold My Beer SEO?
All of which makes this Edge SEO jazz more exciting. Code freeze? Meh, hold my beer.
— Sam McRoberts (@Sams_Antics) February 14, 2019 (opens in a new tab)
Let's be clear on something: we're big fans of Edge SEO.
But in order to use it responsibly, you need to have all your bases covered.
Edge SEO introduces an extra dimension of complexity into a system that's often already complex.
And you need to address this appropriately. Judging from all the queries and concerns, we didn't do so in the interview, so we'll make another attempt here.
Being able to modify site contents at the CDN level is a powerful feature in that it enables administrators to quickly and easily modify everything from security headers to SEO configuration without redeploying the entire site.
But as with most powerful features, it carries risk in that as quickly and easily as you can make productive changes, you can also make destructive changes. I'm personally a big proponent of Cloudflare Workers as they solve a bunch of problems that were previously difficult to address, but I'm also enormously cautious of how I use them given their ability to fundamentally break the site.
The best approach is to ensure it's only sufficiently skilled individuals who have access to configuration at this level and that they comprehensively test all changes before deployment.
Responsibility and accountability
Discuss with the digital marketing and development teams to define who will be responsible for the website's overall health when you adopt Edge SEO. Are the developers still responsible, or have they passed the torch to the SEO team?
Say the SEO performance of the website tanks because of something that was changed using Edge SEO. Who's responsible and accountable for that?
Changes: who should make them, and where?
You used to only be able to make changes to the site through changes in the codebase and—if you were using one—the Content Management System. With Edge SEO, there's now yet another place where you can make changes.
Define what changes to make where. And who makes the changes. Do they go through the development team (as was the case before Edge SEO), or does the SEO team now make changes too? And do certain types of changes remain off-limits to the SEO team?
Development and release management
How does Edge SEO fit into the "infrastructure as code" DevOps movement? How do you fit the configuration of Sloth or the Cloudflare Workers into your existing code repository?
When adopting Edge SEO, you also need to adjust your testing- and release-management procedures as well. It's essential to ensure that the staging environment is using Edge SEO too: Otherwise your staging environment isn't a sound representation of the production environment. This setup will also come in handy for debugging, which we'll touch on later.
Debugging
Debugging a website that's using Edge SEO can be a huge pain. Where do you start when diagnosing an issue? The issue could be in the codebase, it could be in values defined in the CMS, or it could be in the changes you've made on the Edge. Or, to make matters worse, a combination of all three.
Plus, you can easily miss things if you're hitting the origin directly because you've set up your hosts file this way, or if your staging environment isn't using the CDN.
You're always going to have bugs, so be sure to tackle how to debug when using Edge SEO head on. Define a debugging process and define how to fix bugs, who fixes them, and where to fix them (in the codebase or on the Edge).
Security
When you adopt Edge SEO, an additional attack vector is introduced. Because the CDN allows you to basically change everything on a website, it's essential to run this by the security team.
One obvious thing to address is using proper authentication methods to gain access to the CDN. But that's not the only thing:
With the advent of DevOps, security has received an opportunity to integrate security processes into the software development life cycle (SDLC). Here automated source-code scanners scan each commit for security issues, and dependencies are automatically checked against a list of versions with known vulnerabilities. With our "Inline" service, we perform additional security code reviews to cover the areas that aren't covered by automated tooling (known as the "automation gap").
All these processes build upon the assumption that the source code presented represents the base truth and is not changed after a deployment. With Edge SEO, this is no longer the case!
Changes made to deployed code after the fact can introduce well-known security issues and can compromise the integrity of an entire site. Being able to change response headers cuts both ways and can also cripple security headers used to enforce security policies in a user's browser.
We can expect to see Edge SEO changes to, for example, the Content Security Policy of a site that only allows certain scripts to be run. With Edge SEO, someone can adjust such a policy to ensure their newly added SEO script is allowed to run. While this may seem harmless, a change like this can have a serious impact on the entire site and should be reviewed by a security expert.
It is paramount that Edge SEO changes be scrutinized by the security processes already in place, and the environments used for dynamic (security) tests should include the required Edge SEO changes and not diverge from the production site.
In addition to the risks of changes made using Edge SEO, there is now also a new risk for the SEO agency. With the ability to access and change websites, they become an attractive target for hackers. Compromising a single SEO agency gives unfettered access to multiple websites, which can now be abused to disclose sensitive information or spread malware.
Please note that the security issues surrounding CDNs apply to any kind of CDN that allows for changes to be made. It's not limited to Cloudflare Workers.
Compliance
Prior to adopting Edge SEO, check with your compliance team to see if Edge SEO may be causing issues on a compliance level.
To name a few possible compliance issues:
- PCI DSS (opens in a new tab): if you're processing payments, your PCI DSS compliance may be impacted.
- Data Processing: depending on how you implement Edge SEO and what solution you choose, your data may be going through servers in the US. This not just relates to Edge SEO, but is a logical result of using a CDN in the first place.
- Data Protection (e.g. GDPR (opens in a new tab) within the European Union).
- ISO/IEC 27001 (opens in a new tab).
Please note that the compliance issues apply to any kind of CDN that allows for changes to be made. It's not limited to Cloudflare Workers.
Conclusion
While Edge SEO introduces a lot of opportunities to make changes you weren't able to make previously, it also changes everything. You need to radically rethink your processes and—now more than ever—make sure your SEO isn't happening in isolation.
Steven is ContentKing's VP of Community. This means he's involved in everything community and content marketing related. Right where he wants to be. He gets a huge kick out of letting websites rank and loves to talk SEO, content marketing and growth.
