Im pushing 4894 aliases with posts having at least 4 aliases… not counting page changes which I have all of since 2006.
For example:
---
title: 'A change for the better #1 - Merrill Lynch to Aggreko'
description: Join Martin Hinshelwood as he shares his pivotal career shift from Merrill Lynch to Aggreko, embracing new technology and expanding his expertise.
date: 2007-08-16
creator: Martin Hinshelwood
id: "331"
layout: blog
resourceTypes: blog
slug: a-change-for-the-better-1
aliases:
- /blog/a-change-for-the-better-1
- /a-change-for-the-better-1
- /a-change-for-the-better--1---merrill-lynch-to-aggreko
- /blog/a-change-for-the-better--1---merrill-lynch-to-aggreko
tags:
- aggreko
- change
- change-for-the-better
- ml
categories:
- me
preview: metro-aggreko-128-link-1-1.png
---
Yes, there are posts linked all over the web that link back to many of these old URL.
What is the statute of limitations on links? Am I crazy to preserve even old links?
p.s. Ive had the same mobile number since 2008 also
Your host may allow you to create a _redirects file (e.g., Cloudflare Pages, Netlify) or an .htaccess file instead of having Hugo generate 4894 redirect files when building your site.
You can set disableAliases to true in your site configuration, then generate and publish the _redirects or .htaccess file to the root of your public directory. For example:
{{ if eq .Sites.Default.Home . }}
{{ partialCached "publish-redirects-file.html" . }}
{{ end }}
The conditional statement in the above means we only execute the code once during each build.
The number of redirects may be limited by your provider or by host performance (i.e., the speed at which it can parse through 4894 rules).
There is a compelling argument to use client-side redirects when you have a large number of redirects. With a _redirects file or an .htaccess file, the server must parse the file on every request: HTML, CSS, JS, images, etc. This can add up.
I tested a _redirects file with 4894 entries on Netlify. A request for the last redirect in the file (server had to parse all lines) took ~40 ms to redirect to the canonical URL. I tested the same site without generating a _redirects file and with disableAliases = false… there’s wasn’t a noticeable difference.
Search engines are advanced enough these days to understand, that a “permanent redirect” is an update to the indexed link. They will load the alias once or twice and then use the canonical link.
You could create your own alias.html layout file and add a tracker. You will see that not much of those old links are loaded anymore.
A _redirects file (or .htaccess or whatever your server system supplies) could be used to for instance do a general redirect from /resources/blog/* to /* and /blog/* to /*, which probably halves your redirects.
In general you want to refrain from redirect-chains (/resources/blog/ to /blog/ and /blog/ to /).
I did remove all redirects from an old page once and kept an eye on 404 errors for instance in ahrefs.com and Google Webmaster Tools. I ended up having to re-add 20 redirects, no others turned up. Those redirects that stay, are the ones from incoming links from other sites.
Long story short:
Clean way: add an alias.html layout with a tracker (analytics or whatever) and collect what ACTUALLY is redirected over time and add those to a general redirect file like htaccess or redirects and then remove the aliases.
Chaotic way: remove the aliases and deal with the fallout.
It never is a bad option to have a proper search engine on your 404 page.
I am using Azure Static Sites so I needed a json file with the redirects in it that I can either use directly, or merge into my staticwebapp.config.json at build…
I’m going to give it a go and see if it works on preview…
UPDATE: Which did not work as max size of routes on Azure is 25kb! Poopy! I think I’d need to add an azure function for that…I’ll stick with the aliases, but now I also have a redirects.json file to play with.
