Deploying InLinks on the Edge

In the SEO world we’re currently living in a tools nirvana, there have never been so many ways to circumvent usual development or scaling issues using off-the-shelf solutions. InLinks is one of those very tools afterall!

One of the coming shifts in tools usage is the potential of moving away from JavaScript (client-side) methods of installing these tools to versions which have the potential of being more reliable & have less impact on performance.

Whilst Google is better at working with client-side rendered code, we as SEOs should still aim for server-side implementations where possible. This isn’t always doable, but utilising the power of Cloudflare workers we have reworked the InLinks code to be utilised “on the edge” and removing the client-side component altogether.

The practical advantage for SEOs is that GoogleBot will “see” the modifications InLinks makes (added structured data or internal links) within the raw html as if it were added server-side on the origin with no emphasis to wait until the page is rendered.

Using Workers on the Edge to Deploy the InLinks Code (BETA)

Workers enable you to create or modify applications on the “Edge” or without having to maintain your own server. They run on the infrastructure of Cloudflare (Akamai & Fastly also support this), which means when the application is run it takes place on Cloudflare’s infrastructure, making it quick & reliable. 

There are many, many uses for workers, from mapping redirects, generating XML sitemaps, streaming usage data (and more), but in this example we can rewrite the InLinks code to function on the edge. Rather than executing the JavaScript when the page is accessed, it all takes place on the edge and – to users and search-engines – the output of the InLinks code is rendered as if it is part of the server’s response.

So every time a user (or bot) requests the page, the Edge Worker runs, the code is served and we all go about our business. This kind of Edge-based solution has been named “edge seo”.

Steps for Installing the Edge Workers

This process should be pretty simple, even if you do not have development experience. Besides one small tweak to some code everything can be done within the interface of Cloudflare.

1. Ensure you have an active InLinks account configured

Create an InLinks account and ensure that you have configured it to meet your requirements. There are useful resources over on the blog which can help you get started.

2. Add your site to Cloudflare 

If you’re not on Cloudflare already, you’ll need to go and get yourself setup – you can follow the guide here. You can create this for free, and low(er) traffic sites may even be able to use workers without incurring costs. More on that later.

3. Create a Worker

If you click into Workers > Overview you will see the option to “create a service”:

Give the worker a name – something recognisable – and then select “HTTP Handler” and “Create Service”. The starter service doesn’t really matter, we’ll be replacing the code shortly anyway.

If you have never set up a worker, you will have to set up a (free) Cloudflare Worker’s subdomain first: 

Once the worker has been completed you can edit using the CLI or “quick edit” as per below:

Now it’s time to add our code:

4. Take the EW code & add your InLinks

Next copy the InLinks Worker code from here and paste it into the editor on the preview window (as below).

Now, we’ll need to setup the Inlinks ID via an environment variable. Click “save and deploy” and then click back to your worker’s page.

Once there, click Settings > Variables > Add Variable

Now we need to declare the variable name – add “INLINKS_PID” (removing the quote marks”).

The “Value” is the Inlinks ID, we need to head into our Inlinks account for that.

The ID number is in the URL of your project’s dashboard on Inlinks.net:

Then head back into CloudFlare, add this ID to the variable & click “save”. When you have finished it should look something like this:

5. Publish

To publish, you need to go back into the settings for your website – Click into “websites”, select the website you’re working on & then navigate into “Workers”.

Next you need to assign the worker to the website you want it to run on. 

In the example below you’ll see that we’ve set it to work across any page (and any subdomain), but you can amend that as required if you don’t want the script running across every page for whatever reason.

Next select the worker & the production environment – click Save & you’re ready to go.

6. Test

There is really not a lot else left to do other than check to see if your modifications are working as anticipated. 

This script should behave exactly as the original JS implementation, but as this is still a Beta we would recommend you test thoroughly to be sure it is not having any unintended consequences.

Benchmarking performance:

As mentioned at the start, one of the advantages of using Edge deployments is that in many instances we should see better performance because we’re taking the emphasis away from JavaScript.

In the test above, the time saving was small, but your saving could be more significant.

Costs of Workers

Workers on Cloudflare are pretty exceptional value for money, for example you get 100k free requests a day – which for a number of websites should be enough to at least run this worker where it is needed. 

If you think the combined human/bot traffic will be greater than this, the current pricing is $5 p/month (and costing $0.15/million requests per month). If you already have Cloudflare setup, the overview reports for each website should give you the number of requests.

Troubleshooting

If you use WordPress, you might have a temporary issue with caching. You can purge Cloudflare’s cache, but there may be others. I found this warning  in my Cloudflare plugin, for example.

It turned out to be a plugin called “WP-Optimize”. I p[urged that cache in the plugin (just a buttin) and the message disappeared. 

It’s not all Cloudflare Though

Whilst this has been a guide for Cloudflare’s Workers, Akamai’s Edge Workers or Fastly’s Compute@Edge can be configured to do exactly the same thing – in some cases with minimal changes to the code from that above. 

What we find is the Akamai & Fastly setups are often more bespoke so copy & pasting worker script without thorough testing is not recommended. It is possible & presents a great opportunity, you just need to be careful & know what you’re doing.

The Potential of Edge SEO

Moving the functionality of tools like InLinks to the Edge or creating new solutions to SEO problems which take place in front of the server/CMS is something we’re hugely excited about.

In the time we have been working on Edge services we have discovered some novel and innovative solutions to long-term problems & if you would like to have a conversation to discuss your challenges with us, we’re all ears.

If you want to discuss how Edge SEO could help you we’d love to chat, please get in touch via the Torque Partnership website.