w3total cache deactivates trailing slash redirect

Your WordPress subpages are accessible on URLs with and without Trailing Slash? It is possible that this is related to the use of W3Total Cache.

In May 2019, I carried out a series of measures to improve the performance of internetzkidz.de with the experiment for WordPress page speed optimization. In the meantime I have found the second problem in the configuration at that time, which has set me back on the way to a better site in the medium term.

I documented the first experience in the article w3total Cache & Autoptimize Conflict Canonical Slash.

Problem: Two subpage versions by Trailing Slash Handling

A few days ago I found out that my subpages and blog posts were each accessible at two different URLs. One version had a slash at the end of the URL, the other did not. So for example the URLs

https://internetzkidz.de/glossar and https://internetzkidz.de/glossar/ both own HTML documents when called.

The expected behavior would be a 301 redirect from the URL /glossar to the URL /glossar/. This would cause users and crawlers to see only one page at a time. The version of the site without trailing slash would practically not exist. This auto-redirect behavior is actually configured by default in WordPress when the user has not intervened in the permalink structure. The basis for this is the .htaccess file on the server.

The whole thing has put a bead of sweat on my brow, because duplicate content can give search engines the impression of spam, which would lead to a worse performance in search results. But more about the assessment of the consequences in a later section.

Solution: Page Cache Method Disk: Basic

If you know the problem and you use the w3total Cache Plugin to cache your WordPress page, I have found the solution:

1. Navigate to General-Settings under the menu item Performance in the WordPress backend.
2. You are now in the settings of w3total Cache.
3. In the section Page Cache (the second section from above) you find the dropdown Page Cache Method.
4. Select the option Disk: Basic from the dropdown.
5. Save the settings.
6. Empty the page cache above the settings as recommended by the plugin.

This makes it clear that the problem lies in the use of the Page Cache Method Disk: Enhanced. When selecting this recommended mode the error occurs. In Disk: Basic mode the error does not occur.

Reason for w3total Cache of the problem

I got the tip with Cache Mode from a WordPress forum. But since then no plugin release has been updated with this bug. So I wanted to check if the plugin developer is responding to support requests. I guarantee that I have described the problem factually! I even pointed out that I’m not a Paying User, but I would be a bit angry if I paid for a plugin with this error.

The answer from w3total Cache came very quickly and taught me the following:

• It is not a bug
• It is just a freedom in plugin development that has not been restricted (trailing slash or not)
• Due to a specification it could happen that other plugins do not work
• A configuration on the server side would be critical because logic between non-slash and slash cannot be mapped.

The exact statement can be read here:

The reason this happens is that page enhanced rules work with and without trailing slash. We don’t know if the user wants the trailing slash or not. So adding a rewrite rule in the Nginx or Apache config, we can’t do that because we don’t know which URLs should be opposite. For example, the contact form 7 plugin doesn’t work with a trailing slash, but we don’t know if the user installed that plugin. So, we don’t know what plugins work with what rules and we don’t want to have to add a million possibilities for each plugin there is

w3total Cache Support

It is annoying for me that the problem will not be solved in a future release, but it is understandable to a certain extent. However, I find it a bit critical that it was developed against the WordPress default configuration.

Assessment of the effects on the SEO performance

From my point of view the effect of the behavior is not serious, but also not negligible. For one thing, I quickly saw that the Canonical tag on the versions without trailing slash was also correctly assigned with trailing slash. That means that Google even got the correct signal for the original URL if it would have come across a version without slash at the end by chance.

Furthermore, the internal links were all set correctly with a slash and the sitemap was also correct, so a normal crawl would not have been able to find the pages by itself.

However: If the pages were to circulate without a slash, this would be a bit annoying in some cases. For one thing, you would make many page-based analyses in Google Analytics even more difficult (/amp/ folders make it enough). The effects on the tracking implementation are to be interpreted similarly. If I had stored complex firing rules for tags in the tag manager (e.g. with Regex or similar), I could not be sure that all tracking pixels on the correct subpages would trigger.

One problem that made the diagnosis of the error much more difficult and delayed is the deactivation of the caching for logged in users. So it seems that I only checked the redirects of the page while I was logged into the WordPress backend. Accordingly I never saw the cached version.