Years ago, in the very early days of Foliovision, we were mostly an SEO and marketing company. We built websites in WordPress since to market our clients’ services they needed a website. These days, as you probably know, Foliovision is a software company, home of WordPress’s most advanced video player FV Player.
In the very early days, our very first WordPress developer was a gentlemen by the name of John Godley1, who is a brilliant mind and a phenomenal WordPress coder, moving later to work full-time at Automattic. John happened to be the author of Redirection, which was partly developed to serve our particular SEO needs. What I liked to do in the old days was create a post, then experiment with both title and slug.
It was early days for Google, changes in title, slug, meta-description could make a substantial difference in ranking.2 Clean 301 redirections were exceptionally important to make this gamesmanship more efficient. I asked John to build automated redirection into Redirection and he did. Unfortunately, over time there were usually performance issues as each change created a new database record. Often with automated redirection, there would be redirection chains. Changing slugs six times meant six 301 redirections, which was enough to attract negative attention from even Precambrian Google. Something was up.
Worse, it was easy enough to create redirection loops. A redirection loop means the visitor would go round and round in circles between the different versions of the post URL. Confusing and worrying for the visitor. Foliovision gave up on automated redirection. For another few years, we would tinker with article titles and article URL but each time we would manually add a redirection. Intermediate URLs would go directly to the latest URL. The original URL would be redirected directly to the latest URL. In flowchart terms, we would have five manually added redirections each going to a single final URL.
The Redirection plugin also played a central role in our first semi-automated service, Typepad to WordPress migration.
Imagine my surprise in 2023 to find that WordPress has built in automated redirections which work flawlessly. These automated redirections have been around for quite a few years. Checking the history of the feature in WordPress code, automated redirections on posts with changed dates has existed since WordPress 4.9.3, five years ago.
Not enough people know about this. We didn’t find out ourselves until recently as John’s Redirection plugin blocked WordPress’s automated redirection services until version 4.6.
I can understand why John would disable the WordPress function. Allowing two parallel functions to work at the same time often wreaks havoc. His early tests probably showed incompatibility. In 2020, though, he worked through the issues and made the following change.
A publisher can both use Redirection (large scale automated redirections such as one uses with migration) and the WordPress automatic small-scale redirection functionality which handles changing either the post slug or its date.
As an example of how automated redirection can help a publisher, let’s take a sport site. Some of their posts require ongoing updates but not a new article. Since their site URLs are year/month/slug-name
any updated article written at the end of a month creates redirection issues. With WordPress post-4.9.3 and John Godley’s Redirection v4.6+, this just works.
In our test we tried to change the post slug for our article on https://foliovision.com/2023/03/chasing-shackleton:
We verified that WordPress saved the old post slug in database, it uses wp_postmeta
:
Once we saw that it saved properly we tried to open that old post URL https://foliovision.com/2023/03/chasing-shackleton:
One thing Redirection was struggling with was repeated URL changes. So we tried to change both post slug and post date:
But fortunately WordPress would keep track of that change without issues:
…and proper 301 redirection would still occur:
Here we verified that it still worked from the original post URL:
And finally once we reverted all of our changes we saw that all the in-between post slugs were saved properly:
So we are really happy to report that this works very well.
-
Pre-WordPress, I had developed the sites myself in html and CSS, using SSI (server site includes). Ironically light sites based on include technology started to become fashionable again five years ago, i.e. fifteen years after the invention of WordPress. Everyone had become so sick of the maintenance and security issues involved in any full featured CMS for what should either brochure sites or a simple weblog. ↩
-
Later site authority and article citation (i.e. links) became the more important factors, until those were excessively gamed by the SEO community. ↩
Alec Kinnear
Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.
Leave a Reply