You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A site's root URL always has a trailing slash, regardless of addTrailingSlashesToUrls #5675
@benface This isn't Craft CMS's related solution but you could solve it with web server. I use NGINX and all trailing slashes at the end of URI that web server match rewrites and friendly 301 redirects it to URI with no trailing slash.
server {
rewrite /(.*)/$ /$1 permanent;
}
Your actual result: https://example.com/en/
After using rewrite: https://example.com/en
As this minor bug is coming from Craft CMS than it'd solved.
@dominikkrulak Thank you. Yes, I know and already do this. The issue is that following a link to the home page causes a 301 redirect (so two requests instead of one), since the original link from Craft contains a trailing slash, and the web server redirects to the no-trailing-slash URL.
Also, while this is definitely a bit awkward for site URLs that include a URI segment (e.g. http://example.com/en), the current behavior makes sense for base URLs without one (e.g. http://example.com/) – as browsers will end up redirecting to http://example.com/ even if you go to http://example.com (no slash). That’s not immediately obvious by looking at the address bar, but try going to github.com and outputting document.location.href in your browser console – it will output https://github.com/.
If use SEOmatic and you're looking for a temporary work-around for this issue, this is how I solved it for our sites temporarily until the fix comes out:
Noticed this issue on my end as well - what is the temporary solution for alternate and sitemaps urls (seomatic) etc? Affects single home page entry url with subdirectory like example.com/de.
Sorry, no. It would be a breaking change (e.g. for anyone doing {{ url() ~ "some-path" }}), so if we ever change it, it would need to be in a major release, but I also don’t consider it a real bug, because URLs always have some sort of URI, even if it’s just /.
While there is a meaningful difference between https://abc.com/foo and https://abc.com/foo/ from SEO/browser caching perspectives, the same is not true for https://abc.com and https://abc.com/ – both are the exact same URL (the former will automatically normalize to the latter).
Interesting; I wouldn't expect site.baseUrl to change depending on this (isn't it static based on how it is defined in the project config?), but rather how URLs are resolved in functions such as url() and siteUrl(). But totally fair!
Activity
dominikkrulak commentedon Feb 25, 2020
@benface This isn't Craft CMS's related solution but you could solve it with web server. I use NGINX and all trailing slashes at the end of URI that web server match rewrites and friendly 301 redirects it to URI with no trailing slash.
Your actual result:
https://example.com/en/After using rewrite:
https://example.com/enAs this minor bug is coming from Craft CMS than it'd solved.
benface commentedon Feb 25, 2020
@dominikkrulak Thank you. Yes, I know and already do this. The issue is that following a link to the home page causes a 301 redirect (so two requests instead of one), since the original link from Craft contains a trailing slash, and the web server redirects to the no-trailing-slash URL.
brandonkelly commentedon Apr 1, 2020
Unfortunately this is going to have to wait until 4.0, because it would end up breaking a lot of templates that currently do things like:
That assumes that
siteUrlwill always end in a slash.benface commentedon Apr 1, 2020
Ah yeah, I see. No problem at all.
brandonkelly commentedon Apr 1, 2020
Also, while this is definitely a bit awkward for site URLs that include a URI segment (e.g.
http://example.com/en), the current behavior makes sense for base URLs without one (e.g.http://example.com/) – as browsers will end up redirecting tohttp://example.com/even if you go tohttp://example.com(no slash). That’s not immediately obvious by looking at the address bar, but try going to github.com and outputtingdocument.location.hrefin your browser console – it will outputhttps://github.com/.mizziness commentedon Jun 8, 2020
If use SEOmatic and you're looking for a temporary work-around for this issue, this is how I solved it for our sites temporarily until the fix comes out:
{% set currentUrl = currentSite.handle == 'english' ? entry.url : entry.url|trim('/', 'right') %} {% do seomatic.meta.canonicalUrl(currentUrl) %}For our sites, this gives us:
It's definitely not hack-free, but it works nicely and it's only one extra line of code in my template.
WHITE-developer commentedon Jun 5, 2024
Very old issue, but it's still there. Any update on this?
brandonkelly commentedon Jun 5, 2024
Sorry, looks like this fell through the cracks. Just added it to our v6 list. In the meantime, the previous workaround will still do the trick.
tibbis commentedon Dec 25, 2024
Noticed this issue on my end as well - what is the temporary solution for alternate and sitemaps urls (seomatic) etc? Affects single home page entry url with subdirectory like
example.com/de.refactor: Ensure that URLs that are a site index URL and have a path …
refactor: Ensure that URLs that are a site index URL and have a path …
refactor: Ensure that URLs that are a site index URL and have a path …
khalwat commentedon Dec 28, 2024
While I think this is largely as non-issue, and will not affect SEO in any measurable way, I've implemented it in SEOmatic.
Craft CMS 3:
You can try it now by setting your semver in your
composer.jsonto look like this:Then do a
composer clear-cache && composer update…..
Craft CMS 4:
You can try it now by setting your semver in your
composer.jsonto look like this:Then do a
composer clear-cache && composer update…..
Craft CMS 5:
You can try it now by setting your semver in your
composer.jsonto look like this:Then do a
composer clear-cache && composer updateGolembivskyi commentedon Jul 8, 2025
Is there any updates about fixing this bug?
brandonkelly commentedon Jul 8, 2025
Sorry, no. It would be a breaking change (e.g. for anyone doing
{{ url() ~ "some-path" }}), so if we ever change it, it would need to be in a major release, but I also don’t consider it a real bug, because URLs always have some sort of URI, even if it’s just/.While there is a meaningful difference between
https://abc.com/fooandhttps://abc.com/foo/from SEO/browser caching perspectives, the same is not true forhttps://abc.comandhttps://abc.com/– both are the exact same URL (the former will automatically normalize to the latter).benface commentedon Jul 9, 2025
Interesting; I wouldn't expect
site.baseUrlto change depending on this (isn't it static based on how it is defined in the project config?), but rather how URLs are resolved in functions such asurl()andsiteUrl(). But totally fair!brandonkelly commentedon Jul 10, 2025
@benface Sorry yeah you’re right. Updated my example to use
url().brandonkelly commentedon Oct 1, 2026
This is now resolved for Craft 6 🎉 (#19723)