Jump to content

Options for trailing slashes and SEO

Peter Knight

Recommended Posts

Had a question about trailing slashes and forcing one or other.

I've a site where most pages can be accessed with AND without a trailing slash



are both accessible and being indexed by Google. It's obviously bad for SEO but I can't seem to make PW respect one and redirect etc.

There is a setting in templates>template>URLs 


Should page URLs end with a slash
If 'Yes', pages using this template will always have URLs that end with a trailing slash '/'. And if the page is loaded from a URL without the slash, it will be redirected to it. If you select 'No', the non-slashed version will be enforced instead. Note that this setting does not enforce this behavior on URL segments or page numbers, only actual page URLs. If you don't have a preference, it is recommended that you leave this set to 'Yes'.

I must be overlooking something as I have 'yes' selected and both URLs are still reachable with no redirect.

What do you guys do to counter this?


Link to comment
Share on other sites

Hello @Peter Knight,

as long as you don't mix both versions in your internal links or XML sitemap, I don't think it is bad. ;)

Here is what Google writes to this topic:

  • Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay. :)

Or could you please explain a little further or provide an link, why it would be "obviously bad"? I am no SEO expert, so that would interest me.

I have never changed the default setting for URLs and never experienced an downside from it. Also search engines maybe indexing both versions both show only the version with slash as results.

Regards, Andreas

Edit: I have missed, that your URLs do not redirect.

Edited by AndZyk
  • Like 1
Link to comment
Share on other sites

Just an FYI - I have that setting on (as is default), and if I link to a page without the trailing slash, it always redirects to the slash version. Any chance you have something that might be hijacking the redirect?

  • Like 1
Link to comment
Share on other sites

I always assumed duplicate content incurred a Google penalty and affected your rankings. Possibly this isn't as much a problem anymore as @AndZyk mentioned and Google gets better about handling it etc.

@adrian I have the usual batch of .htaccess settings, ProCache and and SEO Module. I couldn't narrow it down to any.

Link to comment
Share on other sites



You can do a quick check on your site to see if the URLs:

  1. http://<your-domain-here>/<some-directory-here>/
    (with trailing slash)
  2. http://<your-domain-here>/<some-directory-here>
    (no trailing slash)

don’t both return a 200 response code, but that one version redirects to the other.

  • If only one version can be returned (i.e., the other redirects to it), that’s great! This behavior is beneficial because it reduces duplicate content. In the particular case of redirects to trailing slash URLs, our search results will likely show the version of the URL with the 200 response code (most often the trailing slash URL) -- regardless of whether the redirect was a 301 or 302.
Link to comment
Share on other sites

On 08/08/2017 at 0:12 AM, AndZyk said:

Or could you please explain a little further or provide an link, why it would be "obviously bad"? I am no SEO expert, so that would interest me.

The post you linked to actually mentions two reasons why this might be bad: it could be identified as duplicate content and it could have a negative effect on crawl efficiency. Neither is something you should really worry about in this case, but then again: Google is a black box (it's impossible to say for sure how their algorithm works), that article is from 2010 (things have changed a lot since then), and some SEO experts do seem to love their micro-optimisations :)

Although in that article they go on to say that their indexing process "often" automatically detects and corrects this issue, it is also true that this is one of those things that are so easy to fix that, even for a tiny theoretical chance that it could affect your rankings, you should stick with one URL format.

On 08/08/2017 at 9:38 AM, Peter Knight said:

I always assumed duplicate content incurred a Google penalty and affected your rankings. Possibly this isn't as much a problem anymore as @AndZyk mentioned and Google gets better about handling it etc.

According to various sources there's no penalty for duplicate content, especially not in cases like this. It would seem that the only way you can get penalised is if Google thinks you're trying to deceive them somehow with said duplicate content. I highly doubt that the trailing slash issue would count.

  • Like 3
Link to comment
Share on other sites

On 8/8/2017 at 0:16 PM, teppo said:

some SEO experts do seem to love their micro-optimisations

That's the whole thing in a nutshell. Don't sweat the tiny details

FWIW I don't think of the 'duplicate content penalty' as a penalty per se, more a discounting of the value of any content that is identified as a duplicate of some other content that is counted. If there is a negative, it's that it costs your crawl budget. By which I mean that say Google is prepared to crawl 10 pages of your site per visit, if 2 of those pages are the same content under very slightly different URLs, you are blowing the opportunity to have another actual different page crawled.

Having said that, and getting back to the point, there are any number of more significant things to be spending time on.

  • Like 1
Link to comment
Share on other sites

43 minutes ago, DaveP said:

FWIW I don't think of the 'duplicate content penalty' as a penalty per se, more a discounting of the value of any content that is identified as a duplicate of some other content that is counted.

I might be misunderstanding what you meant by "discounting of the value" and "counted", but the sources I've read so far seem to say that, behind the scenes, duplicate content is automatically bundled together under one canonical URL by Google. In this case it could mean that, for an example, all links to example.com/foo and example.com/foo/ would count towards the version that Google deems "primary", and it would also be the only one they display in their search results (unless the user specifically chooses to show duplicate content).

Possibly the most common problem with duplicate content is that Google could choose a different version as the primary one than what you might prefer, unless you use canonical tags to advice them. Probably the most fearsome problem, on the other hand, would be that they could think that you're trying to copy same content over and over as an attempt to "cheat", in which case they could remove some pages, or even the whole site, from their search index. But again, I highly doubt that they could ever interpret a trailing slash issue as such an attempt :)

I must admit that crawl budget was a new concept for me. After reading a bit about it, I'd say that it definitely won't be an issue for the vast majority of us here (first of all in a blog post they say that it usually only affects sites with thousands of pages), but it's definitely something that very large sites, or sites that auto-generate URLs in some way, should take into consideration. Anyway, thanks for sharing this point of view! :)

  • Like 1
Link to comment
Share on other sites

2 minutes ago, teppo said:

all links to example.com/foo and example.com/foo/ would count towards the version that Google deems "primary"

Absolutely - Google is quite often wrongly thought to be the enemy. Not at all, unless people are trying to cheat in some way. They actually do their best to understand broken site architecture, which is something that PW does a great job of helping us avoid anyway.

And we can easily go for a belt & braces approach by adding

<link rel="canonical" href="<?=$page->url?>">

in our site's <head>...</head>, letting PW handle it. (Might very well be unnecessary, but can't hurt.)

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

It seems that when using ProCache there is no redirect, both pages produce a status 200. SEO experts/tools seems to feel this is a fault with PW. Adding no or several /// trailing slashes all return a regular undirected page.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By SwimToWin
      SEO matters and so hiding pages behind a "section" is not necessarily good - example:
      Current practice is to show the pages "Foo, Bar, Baz" in a section. https://www.example.com/resources/foo https://www.example.com/resources/bar https://www.example.com/resources/baz For SEO reasons, it's better to show the page at root level like so: https://www.example.com/foo https://www.example.com/bar https://www.example.com/baz PROBLEM: LACK OF ORGANIZATION WHEN ALL PAGES ARE PUBLISHED AT ROOT LEVEL
      This design is fully possible today. However, the root folder becomes disorganized when all pages are published in the root - and the pages tree structure is not of much use when all pages are published in the root.
      As a publisher, when publishing many pages that have a root level url, I want to organize my pages below a Virtual Page (that doesn't have a url), so that pages are organized in a Pages Tree Structure (using "Virtual Pages").
      What is a "Virtual Page"?
      Virtual Page can never have a name (Admin -> Page -> Settings -> Name). The Name field is simply blank The Name field is never used in the url for child pages. Virtual Page is a container used to organize other pages. Virtual Page is never shown in the front-end. Virtual Page is shown in the Editing interface only. Virtual Page might have a Template - but the template can only be used in the Admin interface. Virtual Page might have fields (Title, Summary, Text etc.) - but the contents cannot be shown online.
    • By Sanyaissues
      I hadn't developed a website for a while, but here we are. It's a very simple minimalist website to showcase the latest work of Dominican Artist Patricia Abreu Mota.
      Site: https://patriabreu.com
      Procache ❤️ Seo Maestro Profiler Pro Lister Pro ProcessRedirects
    • By Mike Rockett
      Docs & Download: rockettpw/seo/markup-sitemap
      Modules Directory: MarkupSitemap
      Composer: rockett/sitemap
      ⚠️ NEW MAINTAINER NEEDED: Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there.
      MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added.
      Example when using the built-in multi-language profile:
      <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process.
      The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO).
      Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.)
      As of December 2017, you can also exclude templates from sitemap access altogether, whilst retaining their settings if previously configured.
      Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level.
      The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set).
      Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own.
      Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.
    • By jploch
      Hey folks,
      currently Iam working on a website for one of my clients and I need some advice on how to approach this in PW.
      The website is for a company, that offers holiday houses in two locations. 

      The client wants the homepage to show the first location. Normally I just have a home template for the first page, but here the URL should reflect that you are in Location 1. So when you visit the URL casamani.com it should redirect to casamani.com/location-1. Not sure if this makes sense at all.

      Whould it be bad for SEO and performance reasons to redirect home to the Location-1 page?
      Another approach would be to render the Location-1 template on the home template or do an include like discussed here.
      Here is how the tree looks:
      – Home
      – Location 1 (Homepage)
           – Creation
           – Adventure
           – Sustainability
      – Location 2 
           – Creation
           – Adventure
           – Sustainability

      Thanks for looking into this!
    • By daniel_puehringer

      so we all know about SEO and the importance of performance. Basically we do it, because if no one finds the website we just built, it´s frustrating. We all try to write clean markup, css and js code and most might have a webpack/gulp/whatever pipeline to minimize css&js.
      But when thinking about it, optimizing your pipeline might save you a few (hundreds) of kb, compared to loading an image with 1 mb that´s literally nothing and frankly just ridiculous.

      Don´t get me wrong, frontend pipelines are great and should be used, but let´s shift your "I will optimize the shit out of that 3 css lines" focus to something different: try to serve images as fast as possible, this is where the performance boost really happens.

      I´m no pro on processwire so far, but I built a very easy to use picture element, which some of you could find interesting:

      1. the picture comes with 3 different sizes: one for mobile (keep in mind the double dpi, therefore width of 828px), one for tablet and one for desktop
      2. the picture generates a webp version and the original file extension as a fallback
      3. the filesize of each element is rendered within the "data" attribute
      4. lazy loading(sooo important!!!) is done via the native 'loading="lazy"' attribute.

      Please try it out and see the difference 🙂

      I posted this so others can easily optimize their images, but I would also like to hear your suggestions in making it better. Maybe you could decrease the rendering time or maybe you have some easy improvements.

      Please let me know.

      Greetings from Austria!

      <picture> <source data="<?php echo($oElement->repeater_image->width(828)->webp->filesize);?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(828)->filesize) ?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->width(767)->webp->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(767)->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->webp->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->webp->url) ?>" type="image/webp"> <source data="<?php echo($oElement->repeater_image->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->url) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> <img data="<?php echo($oElement->repeater_image->filesize) ?>" class="img-fluid" loading="lazy" src="<?php echo($oElement->repeater_image->url) ?>" alt="<?php echo($oElement->repeater_image->description) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> </picture>
  • Create New...