What Happened When I Removed Dates from My URL Slugs

Why You Shouldn't Have Dates in URL Slugs

When blogging CMS networks like WordPress and Blogger first came out, the default setting for a URL slug was something like http://www.yoursite.com/[year]/[month]/text.html. 

This was done mostly to give a journal-style approach to blogging built inherently into the URL. It was a quick way to highlight that one entry was published in March 2009, the next in April, and so on. For a while, it worked just fine and everyone was happy. But as blogging became a developed industry with the expressed focus on evergreen content, the concept of having dates in the URL clashed.

For those who write articles that can be relevant today, tomorrow, a year from now, or five years from now, having an explicit date in the hyperlink immediately calls into question the post's relevancy- even if it was updated with new content to keep it fresh. When choosing to click between two articles in search, would you pick one with a 2013 date visible or one with a recently updated date / no date at all?

If you pick the 2013 article I have a lot of questions for you.

For the longest time, we got around this with the WP Last Updated and WP Last Updated Info plugins to show the last updated date inside our articles. This had a bonus effect of showing the last updated date in search results before the meta description as well in most, but not all, of our articles (see “5 days ago” in the 2nd example above). Sadly, even with this plugin we still had no control over what was displayed in the URL slug, and our original publication date would still be visible (see “2013/09” in the first example). Well, until now.

I finally got fed up with having dates in my URL slug and paid my developer to make the change to remove the [year]/[month] components in our URLs. I knew this was a bit of a risk, as all SEO is tied to your individual URL, which puts a lot of pressure on those who do this kind of work to ensure that all data is maintained properly.

Now, I don't profess to know what all they did on the backend to make it work. It involved a lot of redirects, search and replace, and other server-side modifications that are beyond my pay grade. But I do know is what happened after I made the switch, and that is what I want to dive into more today.

The Results of Removing Dates from URLs

The first thing that happened once the changeover process started was that I received about fifty 404 errors. Given our average hourly traffic and how these 404 errors were clustered, I estimated that most occurred over a period of about 20 minutes when the new links for our ~500 articles were propagating over the internet.

Now, there are a few ways of looking at this. You could think that 50 errors is a large amount compared to our daily average of 2-3, but it also speaks to the testament of knowing what you're doing. Had our developer not implemented our redirects correctly, for example, that 404 count could've gone been in the thousands in the first day alone. In that regards, 50 errors over a period of about 20 minutes isn't that bad.

I'm not certain what threshold would indicate to Google that something is wrong with a site, but it would have to be more than 50 over a twenty-minute period as we saw no long-term effects from this blip. (Likewise, on the second day we had a grand total of zero 404 errors and an average of one per day for the few days that followed.)

Within 24 hours, Google started to re-index our content with the new link structure. Within five days the vast majority of my articles were updated in Google with the new slug structure. By the end of the first week, I couldn't find a single post showing up in Google with the old URL structure on display. Not bad at all!

It was at this point that I decided to make one additional change, and that was adjusting about 85 URL slugs to feature optimized keywords (~17% of total posts). These were on articles published before I migrated from Blogger to WordPress in 2015. Prior to this crossover, I had no control over my URL slugs which were auto-generated based on my article title. As I was already changing my URL structure for every post, I figured this would be the best moment to optimize some articles that were in need of updating. I only am mentioning this here for full disclosure before discussing further results.

So, ignoring 404 errors, what about impression and click performance?

In the first few days immediately following the change, my average search position got worse- dropping from 21 to 24 almost overnight. As my normal fluctuations were between 20 and 22 most days, I can likely attribute this to my URL change. What was interesting was that although my position got a bit worse, my impressions were actually up but clicks were down for a few days.

Considering I could've had a catastrophic collapse in Google performance, this change to me is both nominal and reasonable.

By the fourth day, things swung back around. My position returned to 21, my Google impressions and clicks increased upwards of 15% from comparable days in previous weeks, and my CTR jumped to near-record levels for the month. (Note, this was all before the additional URL slug changes noted above.) As I confirmed there were no major algorithm changes during this period, I have to assume that some of this increase is due to URL changes in search results.

While it is still quite early after my switchover, initial data does seem to suggest that my search performance is going to improve despite a minor hit for a day or two- and that is quite encouraging.

*Notes: I understand that the above images make it hard to see the improvement. It is much more pronounced when looking at traffic on a Wednesday compared to the previous Wednesday, which is hard to illustrate, sadly. The red line is also the average of all data during the illustrated period- roughly half before the change and half after. Average performance before this was lower.

I also had a few side benefits appear from this change that are worth discussing.

First, I did not lose my social share counts as a result of the URL change. My best guess is there are new settings (either on WordPress or my theme) that helps preserve this data when a URL slug is modified. In any event, I was pretty pleased by this side perk as it was something I was quite worried about before making the switch. That being said, we still implement server-side redirects even when making URL changes just to ensure this data is always preserved.

Second, I was having troubles with Google alternating between showing my published date and last updated date in the snippet in search results. Removing these dates from the URL seemed to force many of my articles to use the last updated date exclusively, and seemingly fixed the problem I was having outright. This could very well be the most notable improvement of them all, because I suspect the date in the URL is much less obvious than the last updated date in the meta description.

With these two notes, I cannot say if these are the exact case for my improvement, so it is best to take them as only observations/theories at best. In any case, I'm excited about both of them!

Was Removing Dates from My URLs Worth the Fee?

Honestly, I chose to remove dates from my URLs mostly because it was a cosmetic artifact that implies some of our posts are dated. While some of our posts are indeed dated, most are updated to be evergreen and always relevant (to various degrees). Having dates in our URL simply did not reconcile with that fact.

Prior to making this change, I did not expect to see so many improvements right away. I thought that the URL structure was more annoying to me just because I see it every day (and perhaps not to any given reader), but the initial search improvements suggest that any displayed text or date that implies a post is older will reduce clicks, which makes removing the dates from URLs a potential spot for improvement.

That being said, if my traffic increase continues to hold, the fee for my developer to remove dates would pay itself off in just over a month thanks to the extra traffic compared to our previous baseline. Ignoring all other ways to look at this topic, that payback period is enough to call it a win for me. Whether that payback period is the same for you is something I cannot say, as this is just one in a vast sea of SEO factors that could influence rankings.

Hire Someone for This Task

Now, before you go into your WordPress settings and toggle your hyperlink settings to be only https://www.yourdomain.com/text, I need to stop you. Don't do that.

Simply changing your WordPress settings is only the cosmetic step. The real challenge of doing this is ensuring that every single post is redirected properly in order to retain backlinks, internal links, and all of the SEO benefits you have worked hard to build up over the years.

So unless your blog is brand new and has no SEO value whatsoever, simply changing the setting and walking away is shooting yourself in the foot. I shouldn't have to say it again, but I'm going to- walking into this one blind could end up with disastrous results.

This is why we recommend hiring a developer for this task. We had our former managed WordPress host, Performance Foundry, do this (we're now on BigScoots), and they incorporated all redirects and 404 tracking that was necessary to ensure a smooth transition. You could probably get away in hiring someone for a lower cost than I paid (~$500), but in any case, you should find someone who specializes in this kind of redirect package in order to make the leap.

It is an expensive mistake, but one that is most certainly worth fixing if you are able to justify the cost. For those who blog as their business, as I do, you really have no excuse.

Remove dates from your URLs now!