Hello @all,
i’m running Nuxt.js site on Netlify and bumped into weird issue with HTTP status codes returned for the site root request.
the site is very basic; it is generated by the
$yarn create nuxt-app
Source code can be found here
For some reason Netlify generates different HTTP status codes depending on amount of trailing slashes specified in the request URL:
$ curl -I https://admiring-curie-585c96.netlify.app//// HTTP/2 301
cache-control: public, max-age=0, must-revalidate
content-length: 0
content-type: text/html; charset=UTF-8
date: Wed, 20 Jan 2021 15:17:22 GMT
etag: “7fde36f2c9f0b4b0c390a21dc763ca6d-ssl”
strict-transport-security: max-age=31536000; includeSubDomains; preload
age: 0
server: Netlify
location: /
x-nf-request-id: f0d4b89c-7ce8-4c3a-b983-77ef0ce6e049-35083606
in case of 4+ trailing slashes the behaviour is correct - it generates 301 redirect to /, however in case of /// (three slashes) or // (two), Netlify generates http status 200 and produces the page.
The expected behaviour is to have 301 to / regardless the amount of the trailing slashes.
having http status 200 for /// and // can be treated by crawlers as separate pages even though the page is the same.
is the issue known? are there any workarounds?
Please advise.
Very interesting! I suspect that this is either/or being caused by Nuxt, or our Pretty URLs feature.
Let’s start with Pretty URLs. I can see that ‘Disable asset optimization’ is not checked (therefore AO is active) and Pretty URLs is checked (therefore Pretty URLs is active) for this site. Using these reproductions, particularly this one, we can see that content won’t be duplicated across trailing slash and non trailing slash variants of your site.
So, now I’m scratching my head. I can see that, in your deployed files, you have up to 4 subfolders. I’d be interested to see if, if you created a page such as /1/2/3/4/5/6/index.html, whether the number of slashes you required in order to receive a 301 status code changes. If the number of required slashes does change, this looks like a routing issue in Nuxt.
Lastly, I’d be interested to see what impact the following redirect rule has:
/* / 301
I suspect that it won’t change anything, thus leading me to believe that this is a routing issue with Nuxt. Interested to hear what we find!
Following this thread for sure Though from a pragmatic standpoint, I’m not sure how big a bug this could be — typically hitting a URL with multiple slashes is in itself a bug multiple consecutive slashes like that may be HTTP valid (I’d have to look that up honestly) but would certainly be interpreted differently across different web-servers.
dear Pie,
appreciate your prompt reply.
i suspected that amount of trailing slashes somehow is related to site folders structure.
to verify this assumption i created app with only one page, no subfolders at all.
the outcome is the same:
Still have no clue is the issue related to Netlify or Nuxt.
Regards, Dmitry
P.S. there 2 different urls in the examples above. it’s the same app deployed against different branches with different folders structure. just to have both versions of the app available simultaneously
Turns out that this doesn’t relate to pretty URLs or AO in the slightest! It’s across the board, for all .netlify.app domains. I suspect it’s something to do with how up to 3 forward slashes are required or ‘addressable’ by a URL (with 3 forward slashes being used for localhost, et cetera). I’ll see what the wider team say .
hey @Scott,
thanks for your check. Let’s hope that the wider team can help us find an elegant solution.
As a workaround, to resolve the issue with SEO stuff, i just added canonical link to the site home page, i.e.
For what it’s worth, @dmytro, since your main concern appears to be in regards to web crawlers and duplicate content — unless you’re specifically adding anchor tags that specify a trailing-double-slash or trailing-triple-slash, web crawlers aren’t even going to attempt to load trailing-doubles or trailing-triple paths. It’s very non-standard for webpages to use those paradigms and not something that a web crawler would even attempt to load unless you specifically have anchor tags in your HTML that point it in that direction. Canonical tags aren’t ever a bad thing per se but probably not needed in this case, IMO
That said, we do want this to be right! The wider team agree that there is an issue so I’ll get a bug filed on our end.
In short, different behaviours for / may be expected (based on trailing slash behaviour). Additionally, resolving up to /// is expected. However, for /// at least, the canonical link header isn’t right.
I think // behaviour is OK as this defaults to a canonical link header with / – and so does a URL without a trailing slash. We 301 a trailing slash URL to the non-trailing slash URL, if that’s how the site is configured. Of course, this is for a site with a custom domain so a bit more thought will be needed for any sites without. But, I’ll leave it in the capable hands of our traffic team.
As the impact is low, I can’t promise any sort of quick turnaround on this but I’ll be sure to keep you posted with any developments. Appreciate you sharing your workaround too, @dmytro!
@jonsully i agree - rare and non-standard scenario. Let me share some background info we have received results of SE audit from the agency. they complained that we are non double slash and url with and without trailing slash - friendly. I have no clue when they found urls on our site with multiple trailing slashes because they just don’t exist. adding canonical is a bit overkill, but to be 100% sure we’ve just added it and made seo guys a bit happier
hey @Scott, another note about redirects.
i have configured site with or without www. Domain name with www is set as primary.
if i do request to https://mysite.com// Netlify generates 301 with correct location to primary site (htts://www.mysite.com/).
so yes, there is an issue with redirects for sure
NP with low priority of the ticket - since we identified the source of the issue and have workaround, we can live with it for some time.
in the same reproduction,
Though from a pragmatic standpoint, I’m not sure how big a bug this could be — typically hitting a URL with multiple slashes is in itself a bug 
.