Alternate page with proper canonical tag - htaccess rule

Question

I have been receiving lots of canonical error messages from Google Search Console. Most of the time, the referring pages are my own pages and the urls are correct in the referring page.

Google is indicating that the errors are destination urls without a trailing slash. I.e, example.com/mypage vs example.com/mypage/ However, my permalink structure in WordPress is set to end all urls with a trailing slash. The user declared canonicals are also using trailing slashes according to the page source and Google.

I think the problem is with my htaccess file and a WordPress plugin that has enabled https rewrites. My current htaccess rewrite rule is below.

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

I'm not a regular expression or htaccess expert, but if I want my permalinks to all end with a slash shouldn't this be:

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1/ [R=301,L]

I.e., shouldn't there be a "/" after the $1?

Edit If I type in http:example.com/mypage in the address bar, it still redirects to https://example.com/mypage/.

Plugin Rewrite section (comes first in htaccess file):

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Wordpress Rewrite section (comes later in htaccess file):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Note: After looking at my network tab (as MrWhite suggested) I see only one 301 redirect (not two). I.e., http://example.com/mypage is redirected to https://example.com/mypage without the trailing slash. Additionally, if I use https://example.com/mypage it redirects to https://example.com/mypage without the trailing slash as well even though the url is identical.

Mr White, you are correct, I am using Cloudflare and my SSL is set to strict on Cloudflare.

Request/Reponse Headers:

GET /mypage HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
...
Upgrade-Insecure-Requests: 1
...
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

HTTP/2 301 Moved Permanently
...
location: https://example/mypage/
strict-transport-security: max-age=63072000; includeSubDomains;preload
...
x-redirect-by: WordPress
...
server: cloudflare
...
X-Firefox-Spdy: h2

Answer 1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

There's nothing wrong with this rule. (Although it's not complete by itself. I assume there must be a RewriteCond directive that precedes this that checks the HTTPS status.)

The purpose of this rule is to simply redirect from HTTP to HTTPS, preserving the same URL-path (and hostname) as requested. Yes, it would redirect http://example.com/mypage to https://example.com/mypage. But it also redirects http://example.com/mypage/ to https://example.com/mypage/. If you simply appended a trailing slash to the substitution string then it would redirect /mypage/ to /mypage// - which would not be good.

If you wanted to redirect from no-trailing-slash to trailing-slash in .htaccess then this should be implemented as a separate rule. This rule can also redirect to HTTPS in order to potentially avoid multiple redirects when the HTTP version of the URL (without a trailing slash) is requested - but this should be an edge case.

The problem is unlikely to be in the .htaccess file, unless there is a redirect that removes the trailing slash - although that does not seem to be the case.

You need to make sure that:

1. All your internal links point to the canonical URL with a trailing slash.
2. All links in the sitemap reference the canonical URL.
3. All rel="canoncial" elements reference the canonical URL. (As you mentioned.)

Maybe the GSC error is historical? Did you previously use URLs without a trailing slash?

Also check the network traffic for any redirect chains. Whilst the destination URL contains the trailing slash, maybe there is an intermediary redirect that removes it?!