Custom Liquid URL Redirects

Custom Liquid URL Redirects have less limitations and are more powerful for handling complex SEO needs.

Written By Matt Jones

Last updated About 5 hours ago

Setting up a Liquid Redirects Code Snippet

The best place to run custom liquid redirects scripts is on the 404 page. That’s because if a page is missing, a 404 will normally be the default response from Siteglide, whether or not that page is really missing or if it has moved.

If you’re updating the 404 system page using Admin, updating it can be done reliably in one place.

If you’re updating the 404 page via Siteglide CLI, it can be more complicated as you have to update both the /404 page and the /404 Liquid partial.

To avoid complication, we recommend creating a Code Snippet on Admin and adding it to the 404 system page. That means if someone comes along to edit it on CLI later, they only need to edit in one place.

  1. Create a new Code Snippet

  1. Name the code snippet to make clear its purpose is for adding custom redirects. No need to add any code at this stage. Save the file.

  1. Make a note of your new code snippet’s ID, this can be found in the code snippets list or in the URL when you edit it.

  2. Add the code snippet to the 404 system page, referencing the ID you made a note of in 3)

You can copy the code here, but make sure to use the ID of your new code snippet.

Example
{% include 'code_snippet', id: '1', name: 'Custom Redirects' %}

Using Liquid to Redirect and Change Response Status

Accessing the Current URL

You can access the whole URL using context.location.href or just the main relative path using context.location.pathname. You can also access the first, second or 3rd slugs of the URL using context.params.slug, context.params.slug2 and context.params.slug3 respectively.

To keep the structure of the file simple, it’s easier to start with logic determining the action which will be taken and then have a second part of the file to implement that logic.

Changing Response Status

The {% response_status %} Liquid tag can be used to change the HTTP response status of the page from 404 default to something else - this is used by search engines to understand the status of the page, so getting it perfect is a useful benefit of this approach.

Redirecting the Page

The {% redirect_to %} Liquid tag can be used to execute the redirect to another page. If this is used, the actual 404 page will not be rendered; instead the new page will be returned by the server.

Building the Logic

Example
{% if context.location.pathname == "/old-url" %} {% assign new_url = "/new_url" %} {% assign new_status = 301 %} {% endif %} {% if new_url != blank %} {% assign new_status = new_status | default: 301 %} {% response_status new_status %} {% redirect_to new_url %} {% elsif new_status != blank %} {% response_status new_status %} {% endif %}

If redirecting, you need to set a response_status first, as a bug will be thrown if the response_status is 404 (as default on the 404 page) and you are redirecting.

Example 1 - Targeting a URL by specific slugs

An old site has a webapp list on URL /gallery and a webapp item on URL /gallery/item, but when migrated to Siteglide the URLs will be /our-gallery and /gallery/item. We can use Liquid to target only the URLs starting with the gallery slug, but which don’t have a second slug:

Example
{% if context.location.pathname == "/old-url" %} {% assign new_url = "/new_url" %} {% assign new_status = 301 %} {% endif %} <!-- Example 1 --> {% if context.params.slug == "gallery" and context.params.slug2 == blank %} {% assign new_url = "/our-gallery" %} {% endif %} {% if new_url != blank %} {% assign new_status = new_status | default: 301 %} {% response_status new_status %} {% redirect_to new_url %} {% elsif new_status != blank %} {% response_status new_status %} {% endif %}

We don’t need to set a response status variable in our example 1, because we’re defaulting to 301.

Example 2 - A product has been discontinued

To mark a product as discontinued, you can return a 410 response if no other product is a good match for it. This is slightly more graceful than a 404 response as it indicates deliberateness and will unindex the page without penalising the site:

Example
{% if context.location.pathname == "/old-url" %} {% assign new_url = "/new_url" %} {% assign new_status = 301 %} {% endif %} <!-- Example 1 --> {% if context.params.slug == "gallery" and context.params.slug2 == blank %} {% assign new_url = "/our-gallery" %} {% endif %} <!-- Example 2 --> {% if context.params.pathname == "/products/old-product" %} {% assign new_status = 410 %} {% endif %} {% if new_url != blank %} {% assign new_status = new_status | default: 301 %} {% response_status new_status %} {% redirect_to new_url %} {% elsif new_status != blank %} {% response_status new_status %} {% endif %}

In this example, the 404 page content will still show, but the response code to the search engine will be 410 instead.

If you move your 404 page rendered layout inside the code snippet, you can also change the HTML content to match the new response code.