Edge SEO: Implementing Technical SEO Changes via CDN - How does it work and when to use it.

Welcome to a new, very special edition, very techie edition of Crawling Mondays that is dedicated to edge SEO, implementing technical SEO changes through CDNs directly. In order to cover this topic, I invited today 2 founders, owners of tools that allow us to do this. On one hand, Hamlet Batista, he's the CEO at Ranzas. On the other hand, Dan Taylor, Head of Research and Development at Salt. Salt is the owner of Sloth, that is also an HSEO tool. Just to start with the topic a little bit, HSEO, right? How did you start with it, right? How do you start with your tools and what would you say are the main advantages that you have found through your tools with your clients?

As Aleyda said, we've been credited with coining the term, although Being honest, the practice was around a long time before then. We kind of came across it a few years ago. So Reza, who's one of the co-founders of Salt, is a software developer by trade, and we used to do things on the old AWS Lambda servers. And then really through necessity, we started to find issues with— as platforms were growing and becoming more complex, people wanting to move platforms, say, from like Git Pages through to like WordPress. just little things which were never really mainstream SEO considerations, like GitPages not being able to support redirects, for example. So we just decided, well, the way for a solution around that was to do it through Cloudflare Workers at the time, which had only just come out, to be honest, when we started using it for that. And then other use cases where SEO and the technical side of it hadn't been a consideration early as businesses went out on their digital journeys. For example, setting up 14 different websites with different TLDs for international on separate platforms, separate servers, separate teams, and trying to coordinate hreflang across them in a traditional sense was like trying to herd cats. So it makes sense just to have them all under one master Cloudflare and then map the hreflang.

The scenario that you found initially is like, yeah, you cannot implement directly the the technical configurations, redirects, hreflang annotations. So you came up with the idea, oh, maybe we're able to use Cloudflare Workers for them, isn't it?

Yeah. So Cloudflare Workers is one example. So essentially it's changing the origin response code from a server through that middleware layer to inject, change, modify, remove, transform an aspect of that code so that when it is rendered by the browser, by the search engine, by the user, the code element is there. So it bypasses the need, or in certain cases and edge cases where it's used, it bypasses the need to affect the origin. And it can be done almost on the fly through our middleware, through the worker code. We were using it initially for things like dynamic title tags, especially when companies have sort of price pages which the price changes on depending on the feeds, like OTAs in the travel industry, for example. But then the more Large-scale uses with things like redirects, direct migrations, hreflang implementations, and then even methods to do pseudo log collection on platforms like Salesforce and now Shopify. As you can go Orange Cloud on Shopify and actually do edge SEO, so to speak, on most platforms. Just ways of doing the job just in a slightly different way where platform or dev restrictions wouldn't allow us.

Excellent, interesting. Hamlet, in your case, is your journey similar, a little bit different?

Yeah, my journey is a little bit different, but I think that the easiest way to explain it that I found when I explained to people is it's like a Google Tag Manager for SEO, right? So when people think about it, right, all this stuff, you know, no middleware and all that stuff, because I find it really hard for people to grasp it when you start talking in technical terms. But when you use something that they're familiar with, look, you know, Google Tag Manager. What do you use Google Tag Manager for? Oh, as a marketer, you embed all these scripts and you can manage them. You don't have to rely on developers. So that's kind of like the thing, you don't have to rely on developers as a marketer.

You could also use Google Tag Manager for that matter to also inject many of them.

Yes, but let me tell you the difference, right? Because a lot of the agencies that we work with They immediately get it because they're already trying to do it with Tag Manager. You can do it with Tag Manager, but what are the problems with Tag Manager? What are the limitations? What are the pros and cons of using Tag Manager versus using, you know, RankSense or Sloth that are in the CDN? Is that we're able to make the changes. The only difference is that we're able to make the changes before the page loads. So that's a big difference because you have to wait for the page to load for Tag Manager to make the changes and execute the JavaScript. But as you can imagine, right, there is a lot of problems with JavaScript. If there is problems with JavaScript, right, there is going to be also problems with Tag Manager implementations that rely on JavaScript to inject SEO changes, even though it is able to— you're able to do that. That's one problem. The other problem is really interesting with the Tag Manager implementation. Which is, you know, typically you're talking about big enterprises and you say, oh, there is a person that owns the Tag Manager responsibility, and that person is trained for the Tag Manager for one specific use case, which is to manage scripts. When you tell them that they're also going to be managing SEO, they say absolutely not.

Of course.

So that's what you have to understand, that there's the nuances when you're talking about the Google Tag Manager implementation and actually having the same tag management in the edge, on the CDN. Plus also that in the edge and the CDN, you can do redirects, you can modify headers, you can modify URLs.

You have much more flexibility to implement all the types of configurations. Although you can argue that having that additional layer over what you actually manage on a control directly on your platform. It's also not ideal, as it is not ideal to rely on Google Tag Manager because it can get easily out of hand, right? I understand that you provide a good monitoring system to offer people to stay in control of what is actually shown to the Googlebot and avoid that it goes out of hand quite easily because that is, I imagine, most of the concerns that somebody can have. Like with Google Tag Manager, even if you don't have that additional complexity of having to wait for Google to render the JavaScript or execute the JavaScript, it still feels that you're not necessarily in control as when you have access to directly modify the source of the configuration in your own platform, right? How do you handle that or how do you tackle that with your tools?

Yeah, so I would tell you that everything has pros and cons, right? And it depends on what is your pain point, what is your use case, what is it that you're trying to accomplish, right? And what is actually the return on the time and investment, right? So ideally, the optimal scenario is that the websites They don't even need to be touched because they're perfect, right? And also the site wouldn't change either, right? But that's what I'm saying, right?

Yeah.

And they wouldn't change either, right? So that the owners of the website wouldn't be making changes, breaking things that were already working before, right? So that's what I'm saying. That's the ideal scenario. So the scenario that we have, right, that's not the case, right? The websites are always changing. Google is making changes. The website owners are making changes. Things are changing, so you have to address those problems. So what are the options that you have, right? The option is that you want to make changes, right? The the obvious the obvious drawback of a you know edge tool that is making changes is that you turn off the CDN, you know, you turn off the vendor, you lose the change. It's simple as that, right? You have the changes on your website; you don't lose them. But to make the changes, to put the changes on your site, you have to invest the money in the developer hours to make those changes. When you make a lot of changes, not all of those changes, if your goal is to drive traffic and revenue, it's not going to be 100% of the changes, especially the best practices ones, are going to result in improvement, right? So that's how we present our solution. Look, you know, From a cost-saving perspective, this is your alternative. Here's this beautiful massive audit from Aleyda. You're going to spend all these hours to put it in place and you're going to see a massive lift, but it's not because of every single thing that she implemented. It's because a fraction of that— you use an SEO tool and you implement all these recommendations at a fraction of the time and cost because you don't have to involve developers. And now you learn from the changes that you implemented which ones drove the improvement, and now you have a fraction of the changes that you're going to pass to your development team. And that fraction of the changes, you have guaranteed return on your investment. And that, if you think about what are the implications for that, that your dev team are going to love you because you're saying, look, you're going to implement this stuff, I already vetted that stuff, it's gonna work, it's not gonna be a waste of your time. What are you gonna— when you show them that it's gonna be a waste of their time, they're gonna push it to the top of the queue, right? But if you just say, here's all this stuff from Aleyda, awesome, she's amazing, but they're like, okay, 100 things, you know, that I have to do. Yeah, she's amazing, but I don't know whether all that stuff is gonna be effective, so I'll push it later because I have some other stuff that I that I need to do, because they don't know upfront whether that's going to be beneficial.

No, but now I love that approach because then what you're saying is that you can use HSEO implementations for those, for example, implementations that you know that will be much more complex to implement sometimes by the development team, but you can go and implement them right away there to show them the impact of what it will mean to implement it on the actual platform. So it's much more—

Exactly.

At some point and consistent and better integrated at some point. So you can accelerate the implementation process like this and then avoid the bottleneck also of the development.

Avoid the bottleneck and everything. And that's what I— exactly, that's what I tell you, that it depends on what is the use case, right? Another use case, you know, that I think is the main focus of Sloth and Danny is a lot of platforms are not able to do stuff, right? So you have, you know, can't do structured data, can't do this, can't do that. That's a fantastic use case. Use case, and you said, look, you don't have any other option because your platform doesn't allow you to make this type of change, and this is a beneficial change that you have to do. And that's what I tell you, it depends on what is it that you're trying to accomplish, because some platforms are outdated, you know, banks and all these type of businesses, they don't have any other option but to make those changes in the CDN because it will be too expensive for them to upgrade the platform. You're talking about upgrading from IBM WebSphere 6 The way it's going to be, you're talking about millions of dollars.

In which scenarios you will say that this is not the way to go or it doesn't make sense or might not necessarily be the best scenario to move forward with HSEO?

I mean, for that, it kind of goes twofold. So if your platform can support everything, you have development swim lanes and you're able to implement and own everything quickly, then it logically makes sense to own everything on a single stack and not spread equity across things and introduce technical debt. As kind of Helen's covered, not all, even modern platforms don't have that as an actual propensity to achieve. I see edge SEO very much as being an enabler as opposed to a direct go-to. Yeah, it's a very cool tech. It's a very helpful tech. But if literally every, if that's the only option to get something actioned, which will either prove a business case stop a business hemorrhaging traffic, stop a business hemorrhaging money, and at the change can get it done quicker than the devs can, or at a lower cost than the devs can, yes. If a straight go-to, which I do see some people using— this has been an issue, a concern expressed to me on Twitter by other people as well— that if the first thought is to go to, I'll just do the redirects on the edge, I'll just use Cloudflare Workers, Akamai Edge Workers, Fastly, and Lambda@Edge, if the first thought is to go do that and not actually say, well, I can manage using the .htaccess file and upload it and do it in the same amount of time, that for me is more of a process issue. The other time where I also see edge SEO and edge transformation having issues is when developers and the actual infrastructure owners and the stakeholders there aren't included in the same conversations. Because yes, part of it is that we bypass development queues, but very much developers need to be a part of the conversation because they're still going to be making pushes, they're still going to be making changes, and if we're modifying their origin server, their origin push through the CDN, they're going to potentially— we're going to introduce conflicts, we're going to introduce bugs, and we're just going to complicate the whole situation further. It very much for me needs to be a conversation for the same stakeholders and let them understand what we're doing. Similar to what Hamlet said, that introducing hreflang might be development cost of X, resource time of X. We can do it quicker through this way. In 8 months' time, if you've got a chance to implement it that way, great. If not, we can cover it for 8 months, prevent the business from losing out on potential traffic, revenue, etc.

We specifically try to avoid UX. So there are changes to the website that belong on the CMS, right? So there are, for example, navigational changes, you know, massive URL structure changes. So there are changes that you make on the website, you know, that you have to make to improve the user experience. We try to always skip those changes because we think those belong on the website. You know, this is something that you need. Now, separate from that is if you're doing A/B testing, right? So you're trying ideas, right? You know, the CDN also requires— they also have a CDN tool where they specialize in that, right? So there are also other use cases which are not necessarily things that you are going to change, but more that you are trying to learn whether those are good ideas, that we're trying to experiment. and learn whether these hypotheses are valid or not, right? So those are things that you— that, you know, might make sense to do with that in terms of UX, you know, and SEO, right?

To start wrapping up, what would you say that we haven't yet covered and you think that it's super important that people know about this, right? Because it's still something relatively new. More and more and more people are becoming aware of, for example, Cloudflare, and it's very easy to use and it's even free for certain scenarios, right? So I think that the barrier, that the entry barrier is getting lower in order to take advantage of this type of technology, right? But is there anything that you think that is important that people, companies who are looking into opportunities, possibilities regarding HSU know from?

Yeah, I will close with saying that we haven't talked about automation. So automation is something that this enables. So for us, doing these edge changes is a first phase. It's a stepping stone into being able to add the automation layer. Because once you have the changes so easy to make in the cloud, in CDN, it allows for the automation. You see all the stuff that I do in Python and all the initiatives on Python. That stuff that you can automate in Python, you make it very easy if you're generating a lot of title tags. For example, I wrote an article. Now you have all these title tags that you automatically generated, and then you can publish them on the CDN, learn if they're effective, and then see, wow, these automated experiments that I didn't have to type manually actually perform better or worse than I thought, right? So that is something that I think, you know, it's still baby steps there, but I think this is kind of like laying the groundwork. It's like providing the highway for you to be able to add these automation capabilities and leverage all this automation in a way that you can deploy quickly and see the kind of impacts. So I think that the massive productivity—

And the testing, I will say automation and the testing.

The automation with the testing, exactly. So that's what you see, that's why, you know, for us this has been like a stepping stone into what we wanted to build, right?

That's a great thinking and vision for sure. Dan?

I mean, for us it's as much about making sure that people understand the accessibility of this. I mean, as you said, Cloudflare offer a free plan, they offer a certain number of worker requests for free now. Most enterprise businesses will be on a plan which allows heavy support, especially if you do user, if you specifically filter by user agent token, which a lot of edge SEO requests will need to be, especially with like pseudo-login redirects for users, Googlebot, etc. The important thing for me is also understanding that Lambda— sorry, AWS, you can do Lambda at edge, so you can do transformations there. Fastly also have a solution based on WASM now as well. And Akamai Edge Workers Also exists with like the limitations Hamlet spoke of a few years ago, which Akamai had with regards to doing URL rewrites for content still being in there. They now have edge workers, which I think on the next release will pretty much be able to do everything that Cloudflare workers can do. And again, all runs through Aviary Performance. In October.

What, sorry? In October they're gonna—

Yeah. It's all coming together basically. Most websites of a certain size, most businesses of a certain size will have a CDN. Not necessarily part of the optimization or speed stack, but as part of the sysadmin stack for security anyway, because that's the way they've been built. So the opportunities are there and it's just something that's definitely worth exploring. If we can't do— I mean, our role as SEOs is essentially to help businesses drive value and show ROI. And this just offers another avenue to explore and another avenue in which to do so. Where, I mean, for example, I've just done an ecommerce migration to SAP Hybris for a large number of SKUs, modern platform, very modern company, heavy advertising, can't handle that many redirects. So we do it on the edge and that keeps a business ticking over, keeps them moving even over platforms, CRM going. It's kind of where we're starting to not become dev lights, but as Dan Liebsohn says, but also just become more integrated into the wider Stack and platform.

This is amazing. I think it gives like a much better, wider, proper view about all the possibilities, right, regarding—

Some of the possibilities, yes.

Yes.

Thank you very much. And of course, if you want to learn more, Please go and leave your comment below here in the video. If you have indeed any questions, any doubts, I'll tag Hamlet and Dan so they can answer any question or any doubt that you may have. If you want to test it out, check and take a look at Vansense and Sload, especially if you're already using CDN. Thank you very much again for watching. And if you liked the video, remember to like the video, to subscribe for more videos, of course, And, uh, looking forward to share in the next Crawling Mondays. Thank you very much, Hamlet. Thank you very much, Dan, again. Bye-bye.

Crawling Mondays.