27 March 2023
An unexpected issue when setting up 301 redirects in Shopify.
The previous Absolute site was on an old Expression Engine system that was increasingly showing its age and was difficult to manage content - especially compared to the newer platforms we were building for our clients. So when looking at which platform to use, we took the unconventional approach of using Shopify as our content management system. The site isn’t transactional in any way, but we get the benefit of Shopify’s lovely drag and drop content editor and it’s meant we can very easily build great looking pages.
Shopify seemed the clear choice and it all went very smoothly until almost at the very end when we started to look at the 301 redirects. With any site launch care needs to be taken to ensure that existing pages are mapped correctly to their new locations. Shopify has particular URL structures, so all content pages need to have /pages/
in the address for example. We were well aware of this and we’d just use the built-in Redirection system to handle any requests to the old address to show the new page. For example on the old site we had a page at absolute-design.co.uk/about-us
but on the Shopify site it would need to be absolute-design.co.uk/pages/about-us
We worked with our SEO partner to generate a list of the existing pages with the corresponding new address and then it’s usually a simple case of uploading that as a csv file into the Redirection area of the admin. It was all imported successfully and that should have been job done.
Except when our SEO partner ran a redirection report there were over 140 addresses that weren’t redirecting. When we looked at those addresses we spotted the pattern that they all began with /services/
- so what was going on?
It didn’t take long to find this on the Shopify documentation:
You can't redirect URLs that begin with the following prefixes: /apps, /application, /cart, /carts, /orders, /shop, or /services.
We were aware and expected some of these - but /services
? When we contacted Shopify Support even they weren’t sure what that address was reserved for - it’s certainly never used on most Shopify stores.
Being an agency offering a variety of services, we obviously had a large number of pages under that /services/
structure and would absolutely need to redirect those, otherwise all historic marketing activity would be linking to pages that no longer existed. And it wouldn’t even send the visitor to the 404 page to be able to get them back on track - you can try it with any Shopify store, absolute-design.co.uk/services/test
for example, you just get an ugly ‘Something went wrong’ page.
If it had gone to the 404 page within the theme, then we could have used the request
object and done something clever there to forward the user to the correct content. However it never actually gets to the theme code so we were going to have to step back up the chain a bit to find a solution…
Our first idea was to try and use Cloudflare to do the redirection before it got to Shopify. We knew that Shopify uses Cloudflare itself so thought we might be able to work with that, but it turns out that wouldn’t be possible. We could set up our own instance of Cloudflare in front of Shopify’s using what is called Orange-to-Orange and do the redirections there, but this is only available on Cloudflare’s Enterprise plan, so we wanted to explore more cost effective solutions first.
Shopify also uses Fastly to run its CDN to deliver all the assets for store fronts, so we thought we’d try there next. The idea being that we could use Fastly’s Varnish Configuration Language (VCL) to add a dictionary of all of the redirects we wanted and some VCL scripts to handle the redirect, correctly sending a 301 response and directing to the new content.
It took a bit of juggling to get all of the systems to play nicely, and the biggest issue was maintaining the security certificates so we could use secure https
addresses. Normally Shopify provides this all for you as part of the service, but we needed an additional SSL certificate within Fastly so that that first connection was also secure. Once we’d got that in place and configured, we could point the domain to Fastly’s services, it would run through the VCL scripts and then forward the corrected URL to Shopify’s servers and we’d get those redirects that were so important to maintain.
And it worked - you can try it for yourself, here’s one of the old services links that would ordinarily have shown that error page - absolute-design.co.uk/services/frontend-development
It was a completely unexpected issue to come across - we set up Shopify redirects all the time for clients - but having found a solution for this particular edge case using a little ingenuity was very satisfying.