Why my Redirect rules from 2013 still work and yours don't

Here is something that makes me proud of my blog. The redirect rule I wrote for my very first article 12 years ago still works! This blog was an experiment. When I designed it, my intention was to try everything possible and not care if it broke. In fact, I often said that if anything broke, it would be an opportunity for me to face a new challenge and learn. I designed the website as best as I could, hoping that it would break so I could fix it. What I didn't take into account was that some things are much harder to fix than others. More specifically: URLs.

Originally, this was the format of the URL:

idiallo.com/:article-name

You can blame Derek Sivers for that format. But then I thought, what if I wanted to add pages that weren't articles? It would be hard to differentiate a blog entry from anything else. So I switched to the more common blog format:

idiallo.com/blog/:year/:month/:article-name

Perfect. But should the month have a leading zero? I went with the leading zero. But then I introduced a bug:

$year = (int) $req->param($year);
$month = (int) $req->param($month); // 09 becomes 9

Yes, I squashed the leading zero from the months. This meant that there were now two distinct URLs that pointed to the same content, and Google doesn't like duplicate content in its search results.

Of course, that same year, I wrote an article that went super viral. Yes, my server crashed. But more importantly, people bookmarked and shared several articles from my blog everywhere. Once your links are shared they become permanent. They may get an entry in the wayback machine, they will be shared in forums, someone will make a point and cite you as a source. I could no longer afford to change the URLs or break them in any way.

If I fixed the leading zero bug now, one of the URLs would lead to a 404. I had to implement a more complex solution. So in my .htaccess file, I added a new redirect rule that kept the leading zero intact and redirected all URLs with a missing zero back to the version with a leading zero. Problem solved.

Note that my .htaccess was growing out of control, and there was always the temptation to edit it live. When I write articles, sometimes I come up with a title, then later change my mind. For example, my most popular article was titled "Fired by a machine" (fired-by-a-machine). But a couple of days after writing it, I renamed it to "When the machine fired me" (when-the-machine-fired-me).

Should the old URL remain intact despite the new title? Should the URL match the new title? What about the old URL? Should it lead to a 404 or redirect to the new one?

In 2014, after reading some Patrick McKenzie, I had this great idea of removing the month and year from the URL. This is what the URL would look like:

From: https://idiallo.com/blog/2013/10/pc-is-not-dead-no-need-for-new-ones
to:   https://idiallo.com/blog/pc-is-not-dead-no-need-for-new-ones

Okay, no problem. All I needed was one more redirect rule.

I don't like losing links, especially after Google indexes them. So my rule has always been to redirect old URLs to new ones and never lose anything. But my .htaccess file was growing and becoming more complex. I'd also edited it multiple times on my server, and it was becoming hard to sync it with the different versions I had on different machines.

So I ditched it. I've created a new .conf file with all the redirect rules in place. This version is always committed into my repo and has been consistently updated since. When I deploy new code to my server, the conf file is included in my apache.conf and my rules remain persistent.

<VirtualHost *:80>
    ...

    # Redirect rules for removing dates from url
    Include /path/to/redirectrules.conf

</VirtualHost>

And the redirectrules.conf file looks something like this:

RewriteEngine  on
RewriteRule     ^/blog/2013/04/dealing-with-mysql-once-and-for-all\.html    /blog/dealing-with-mysql-once-and-for-all.html  [R=301,QSA,L]
RewriteRule     ^/blog/2013/04/never-take-user-suggestion-seriously\.html   /blog/never-take-user-suggestion-seriously.html [R=301,QSA,L]
...
RewriteRule     ^/blog/from-zero-to-20-books    /blog/reading-is-useful [R=301,QSA,L]
RewriteRule     ^/blog/google-can't-build-instant-today /blog/google-cant-build-instant-today [R=301,QSA,L]
RewriteRule     ^/blog/fired-by-a-machine   /blog/when-a-machine-fired-me [R=301,QSA,L]

I've rewritten my framework from scratch and gone through multiple designs. Whenever I look through my logs, I'm happy to see that links from 12 years ago are properly redirecting to their correct destinations.

URLs are forever, but your infrastructure doesn't have to be fragile. The reason my redirect rules still work after more than a decade isn't because I got everything right the first time. I still don't get it right! But it's because I treated URL management as a first-class problem that deserved its own solution.

Having a .htaccess file living only on your server? It's a ticking time bomb. The moment I moved my redirect rules into a .conf file and committed it to my repo, I gained the ability to deploy with confidence. My redirects became code, not configuration magic that might vanish during a server migration.

Every URL you publish is a promise. Someone bookmarked it, shared it, or linked to it. Breaking that promise because you changed your mind about a title or URL structure is not an option. Redirect rules are cheap and easy. But you can never recover lost traffic.

I've changed URL formats three times and renamed countless articles. Each time, I added redirects rather than replacing them. Maybe it's just my paranoia, but the web has a long memory, and you never know which old link will suddenly matter.

Your redirect rules from last year might not work because they're scattered across multiple .htaccess files, edited directly on production servers, and never version controlled. Mine still work because they travel with my code, surviving framework rewrites, server migrations, and a decade of second thoughts about URL design.

The Internet never forgets... as long as the redirect rules are in place.

---