New Distilled ODN features including SEO friendly URLs for enterprise platforms

If you’re a regular reader of our content, you’ve probably come across our ODN platform which enables both SEO A/B testing and more agile changes to large and enterprise sites.

Earlier this year, we had a quarter where we deployed our platform to two Fortune 100 companies’ sites and to the website of one of the largest private companies in the UK. I’ve written before about the ways that split testing is changing consulting but what we’ve found in these enterprise environments is that we are getting radically different results by adding agility to the mix. Perhaps unsurprisingly, it turns out that sometimes, being able to get stuff done is a differentiator in the enterprise. My research showed that the average SEO at a big company has been waiting over six months for their highest priority technical change and doesn’t anticipate seeing it deployed for at least another six months. Indeed 40+% have been waiting over a year!

It’s been very rewarding to attack this problem directly: our core values have always been skewed towards getting things done above simply identifying what needs to be done. Now we are hearing from our customers things like: the ability to make changes to local store pages has been one of our most successful initiatives this year, we’re up 10% and seeing the impact on footfall (that was from a Fortune 100 company - and +10% is pretty visible and meaningful in that kind of environment).

We have new functionality in the ODN

As part of improving our platform’s value in these kind of situations, we are just finishing up a series of enhancements that will be rolled up into a launch we have internally called REQMOD.

The key things this will enable us to do via the ODN platform are:

1. Move pages individually or en masse (e.g. to serve content on SEO friendly URLs without parameters and redirect the old pages)
2. Move sub-domain content into sub-folders
3. Enable easy SEO A/B testing of full page redesigns

Key benefit #1: Moving pages or folders of content

We often come across enterprise-scale sites built on technologies that rely heavily on parameters. It’s really common to see, for example, e-commerce sites built 5+ years ago with no keywords in the URLs at all and often multiple query-string parameters (e.g. /store/product?id=product_id&style=style_id). In fact, there are myriad ways that URLs can be less-than-perfect for users and search engines.

In general, it’s easy to fix this on small or personal sites. A bit of .htaccess fiddling, some rewriting and a redirect or two is all it takes. The complexity (and what’s at stake) is much greater on enterprise platforms.

Having spoken to a bunch of large sites who’d buy a solution to just this problem, we figured it was a great thing to build into our platform since we have all the moving pieces. So - with this release, our platform:

• Returns the correct page content on a request for the new (“pretty”) URL exactly as if the origin server was configured to serve it for that request
• Returns 301 redirects at the individual page level for all the old URLs to the new pretty ones

This feature also makes it easy to create new pages by pulling in the outline of a page you want to base your new page on and updating key information (title / meta information, body content) without having to recreate menus, footers etc. It works in a very similar way to moving a page, but with no associated 301.

Key benefit #2: Move sub-domains to sub-folders

Despite the official line coming out of Google, we know that this is still important:

Are you in need of 14 case studies to back up the assertion that:
Moving subdomain -> subfolder (almost always) increases search traffic
Moving subfolder -> subdomain (almost always) decreases search traffic
I got your back. Thread /1

— Rand Fishkin (@randfish) March 14, 2018

(The difference between the carefully-worded technical correctness of official Google statements and what happens in the real world is something that’s well-worth being aware of. If you haven’t dug deep into it, I recommend this whiteboard Friday on precisely this topic and history and background here [video for DistilledU subscribers]).

The point being, in the real world, this is something you might well want to do.

It can be tricky though: often sub-domains are created because they run different software stacks and / or use different servers, or even because they point at fully external hosted services. It can be hard or impossible to integrate them into your core web servers and so sometimes the only way to host them from a sub-folder is via technology like the ODN that deploys into the web server stack.

In a similar way to the way that the new features enable the ODN to move pages from one path to another, we can also modify the request to origin to go to a different server entirely, enabling us to move sub-domains into sub-folders, for example:

• Redirect all blog.example.com/path pages to www.example.com/blog/path
• When www.example.com/blog/path is requested, serve the content from blog.example.com/path

As per Rand’s tweet above, many sites have seen significant benefit from this kind of change, and deploying our stack will make it super easy to manage.

Key benefit #3: A/B test complete redesigns

Everyone who has ever had to release a major redesign of a bunch of pages that get significant organic search traffic has worried about the potential impact the redesign will have - and rightly so. There are a ton of horror stories about this kind of change going wrong. Some parts are avoidable with diligent processes - there are horror stories of brands moving to entirely JS-rendered content that flummoxes search engines for example, that could be avoided with SEO input to the new design - but some parts remain inevitably nerve-wracking.

When you redesign a page, you almost inevitably change its HTML, and it’s virtually impossible to tell in advance how Google will view it. Even further: in a world where usage signals play a role, it’s clear that it’s only on launch that you’re going to begin getting the feedback loop from new design to users’ response to it to Google’s response to that.

So. Your nerves are wracked. Now what?

Well - the new tech enables to make it easy to roll out the new design to just a small percentage of pages, and so as long as you have enough pages and enough traffic, you can run an A/B test to see how they perform in the search results. This is different to the kind of testing you can do with CRO / UX testing tools as it’s visible to the search engines and specifically designed to measure the impact on search performance.

The first test like this that we ran for a customer was strongly negative. I mean, strongly negative. We knew that this customer liked the new design and wanted to deploy it, but getting this insight about its impact on traffic and revenue enabled an iterative approach to understand what still needed to be tweaked and user-tested and then tested again for search impact before pushing the button to roll it out across the site section.

Much like the sub-domain example above, this piece of functionality can work by routing requests just for the variant pages to a new server while routing the control pages to the existing origin server. Alternatively, depending on your setup and configuration, another option is for our platform to inject a header into the request for variant pages (e.g. x-split-test: variant) and to have the origin server respond with the new template when that is present, and the old template when it’s not.

Get in touch if you want to see the ODN in action

If you work on a site that is suffering from an inability to make these kinds of changes (tidy up URLs, move pages or site sections, transfer content from a sub-domain to a sub-folder and more) then get in touch to see a demo of our platform in action.

Similarly, if you have a redesign of a large site section coming up, and you’re nervous about the impact on organic performance of deploying a totally new template across hundreds or thousands of pages then you should check out our ability to split-test at the template level and see how it performs on a smaller number of pages before you hit the big scary button.

Distilled