We need to talk.
Since I spoke about Edge SEO and Cloudflare Worker techniques at TechSEO Boost 2018, as well as my Edge SEO article in December, there has been a lot of conversation and excitement about what could be a new frontier if not only for SEO, but also for how we approach problem solving and development issues as a whole.
This goes beyond whatever people interpret edge SEO to mean, it covers all CDNs and serverless technologies.
Using CDNs for the benefit of SEO isn’t something new, it’s something a lot have us have been doing for a number of years. At SALT, we wrote this post back in 2015 looking at potential SEO issues of using CDNs.
The only difference between what we’ve been able to do previous using wrappers and injecting directly into the CDN, is that we’re now doing it with a serverless application and JavaScript – the concept isn’t new, all I’ve done is invent a new phrase to make it sound “sexier”.
Edge SEO is an easier sell for internal teams than implementing through a JS code on a serverless application, using an existing CDN infrastructure
Edge SEO and using serverless applications like Cloudflare Workers not only open up a world possibilities, but also a new world of potential problems and create the need for new processes and learnings, before companies make mistakes and it costs them traffic, and revenue.
New workflows need new thought processes
In this article, I’d like to openly discuss some of the learnings we’ve made whilst building Sloth (a Cloudflare Worker generator tool) and consulting with brands around wider business concerns, securities, and internal processes.
When people rode horses, no-one thought about the need for seatbelts.
As technologies such as serverless applications, machine learning, and artificial intelligence continue to both improve in terms of core functionality, opening up new opportunities as well as new risks, concerns, and conversations we need to have with wider stakeholders about the adoption of the technologies.
Some of these technologies and their uses don’t necessarily require these conversations, for example Netflix uses machine learning to provide recommendations to users on other films and shows they might be interested in. Whereas Google’s self-driving vehicles use machine learning to drive and navigate live scenarios.
The clear difference between these two examples is one poses a risk to your night in, whilst the other poses a risk to life.
Edge SEO on the other hand, depending on application, poses a risk to the business, so different micro-conversations need to be had about particular uses, as well as a wider conversation about adopting CDNs and serverless applications as part of business processes.
These conversations can really be categorised into the below areas:
- Responsibility and accountability
- Change management
- Development and release management
- Debugging process
- Security
- Compliance (legal, privacy, GDPR)
Whilst doing our research into Edge SEO, building the Worker generator, and talking to businesses about using the serverless apps, we started to realise the scope of new problems that could face businesses and teams moving forward.
Following my interview piece on Edge SEO with ContentKing, Steven Van Vessum wrote a follow-up piece looking at some of the concerns raised.
Edge SEO isn’t without its risks
I love Edge SEO, and I love being at the forefront of what is a new field in SEO. But I’m not going to sit here deluded that it doesn’t bring new risks as well as opportunities. However, it’s also important to understand what Edge SEO is and isn’t.
Edge SEO is designed for edge cases. It’s not a circumvention or an alternative, it’s a hail Mary to bypass restrictions by some platforms, legacy tech stacks (that can’t be replaced due to time and money), and big dev backlogs/lack of resources for crucial fixes.
It is worth noting that a lot of issues facing edge SEO in terms of risk or internal process, are the same as those that exist with traditional development.
Responsibility and accountability
Edge SEO, and platforms such as Sloth and Spark introduce new variables to an already complex ecosystem of technologies and processes, and like with any new technologies introduced there needs to be a conversation around responsibility and accountability within the organisation.
It’s pretty cool, but it feels like using this to “circumvent” the usual processes involved with updating a live site is playing with fire. Instead of the 17+ sign-offs to update a page’s title, you just do it on your own? If anything breaks, will you get blamed by default?
— 🍌 John 🍌 (@JohnMu) 27 February 2019
John Mueller also raised this during a recent Twitter conversation, and I agree with him. However, this is something that needs to come from within the organisation, and may already fall under existing processes.
At TechSEO Boost, Stephan Bajaio asked me a question around processes and business adoption for Edge SEO as well, and in all honesty – the answer is simple:
- The processes have to come from within
- They have to be declared as business processes with an appointed overseer
- They should compliment or be an amendment to existing processes surrounding development and deployment
- All stakeholders already involved in development and deployment should be stakeholders within tools like Sloth and Spark
- Access to Cloudflare shouldn’t be business wide and open (regardless of whether or not you’re using Workers)
- All access to things like Cloudflare should have two-factor authentication anyway
- Testing and QA is still required
Edge SEO tools such as Sloth, Spark, and various Worker code repositories on Github need to integrate with your existing development and change management processes, and not circumvent them.
In the wrong hands and without internal regulation, deploying self-sufficient worker bundles to your production website could cause serious issues for the business.
Access to Cloudflare/CDN credentials
For me, this is one of the biggest things companies need to get right.
Access to your Cloudflare, Akamai, or Incapsula account needs to be locked down within the organisation because even without Cloudflare Workers being enabled, you can still do a lot of damage through the Cloudflare dashboard if you don’t know what you’re doing.
I know this seems like common sense that things like your Cloudflare authentication key need to be locked down to specific individuals in the business, but it needs to be said – Troy Hunt also said this via the aforementioned ContentKing article:
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.
Cloudflare is an extremely powerful tool, as is any CDN, and all CDNs (Akamai, Incapsula) have the ability to influence the website – I covered a lot of these potential actions in my CDN SEO article.
Concerns around data privacy and compliance
Regardless of whether or not you’re legally obliged to follow the GDPR regulations, secure and ethical data handling processes should be your default modus operandi.
Some of concerns I’ve seen raised around using Cloudflare Workers & CDNs is around data transfers both inside and outside of the EU.
Given that CDNs are global businesses, they are well aware of GDPR and that a lot of their customers are located in EU member states, and have acted accordingly to ensure compliance:
It’s important in your data mapping that you’re declaring the use of cloud services, and given that GDPR has been in-place for almost a year now, jf you’re not yet in a state of compliance… Or getting close to being – this is a wider issue than whether or not you can do redirects on a serverless application.
Please let me know your thoughts in the comments section below, I will respond to every single comment.