Hacking the core to have no trail slash as default

[ryan]

I would agree that structurally every page in ProcessWire is (or can be) a directory. Something like /products/ is basically meant to be the equivalent of whatever the DirectoryIndex is (/products/index.html for example, but of course an actual DirectoryIndex file isn't necessary). If you literally wanted to have a /products.html, you certainly could do that by disabling the trailing slash for that page's template and just name the page "products.html". The only time I do that is when I need to duplicate an existing URL from an oldschool site or setup something like a /sitemap.xml that maps to a PW page.

[mindplay.dk]

If you literally wanted to have a /products.html, you certainly could do that by disabling the trailing slash for that page's template and just name the page "products.html".

Well, yes, but technically, products.html is still both potentially a file and folder - if you were to add a sub-page, you would get "products.html/ipod.html" which demonstrates why doing so would be even more wrong and misleading

Don't get me wrong - I love that fact that nodes are homogeneous in ProcessWire. But an option to add a suffix when requesting the actual document (rather than the folder) would eliminate the ambiguity in the URLs - "products" in "products.html" clearly refers to a document, whereas "products" in "products/ipod.html" clearly refers to a folder...

[WillyC]

Well, yes, but technically, products.html is still both potentially a file and folder - if you were to add a sub-page, you would get "products.html/ipod.html"

[/quotamos]

why.you want to do.it ?

.. donut do.it may be.fun sometime

I love that fact that nodes are homogeneous

homo .generos nodes

u. love, ?

notthing.wrong withe that

I .under stand ?

But an option to add a suffix when requesting the actual document (rather than the folder) would eliminate the ambiguity in the URLs - "products" in "products.html" clearly refers to a document, whereas "products" in "products/ipod.html" clearly refers to a folder...

i. like to add a suffox .sometime too.

good flexibile we.have .will try it out

[neildaemond]

Today an SEO expert told me to make all the urls have a trailing slash. With a bit of research, I found out that NOT having a trailing slash is a BAD THING for seo in general. Supposedly a trailing slash will give a 200 return code and no trailing slash will return a 301. I haven't confirmed if this is the case for PW, however.

This blog post talked more about it.

[neildaemond]

hmm.. just tried http://www.seoconsul...m/tools/headers

going to mydomain.com or mydomain.com/ both returned a 200

going to mydomain.com/about-us returned 301

going to mydomain.com/about-us/ returned 200

.... if you hacked the core to remove the trailing slash, would the results be reversed?

so maybe just being consistant is important? It seems that its more common to have the trailing slash then not, however~

edit (more thoughts):

if both mydomain.com and mydomain.com/ return a 200 code, is that a bad thing because that means there is two pages with duplicate content? My guess is that its better to have one redirect to the other, no?

[apeisa]

Neil - it's up to your server and backend what http status you serve - nothing to do with trailing slash.

[mindplay.dk]

Neil - it's up to your server and backend what http status you serve - nothing to do with trailing slash.

I think he means with ProcessWire?

So yes, "mydomain.com/about-us" returns 301, and "mydomain.com/about-us/" returns 200, by default - and having the extra redirect isn't good for your search-engine ranking. In other words, simply giving people the URL "/about-us" when the real URL is actually "/about-us/" is not a good idea. Having both URLs work (actually serving the same content from both addresses) also (generally) isn't good for your search engine ranking - search engines may be more forgiving in this case, not sure. It either case, it'll work - but it's not a good idea.

This is part of the reason I perpetuated the discussion, and I'm still not satisfied with the answer...

[neildaemond]

I wanted to see if it is bad that both mydomain.com and mydomain.com/ return a 200. I did a bit of research and saw this on the google blogs (http://googlewebmastercentral.blogspot.hk/2010/04/to-slash-or-not-to-slash.html):

"If both slash and non-trailing-slash versions contain the same content and each returns 200, you can:

- ...

- Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and can’t be redirected even if you’re Chuck Norris."

and according to sections 6.2.3. in rfc3986 (http://tools.ietf.org/html/rfc3986), which defines how uri syntax works, the following are the same:

http://example.com

http://example.com/

http://example.com:/

http://example.com:80/

So, I'm happy with the default behavior of PW since its consitent with slashes on the pages. The root url doesnt matter if it has a slash or not.

[Soma]

I think he means with ProcessWire?

So yes, "mydomain.com/about-us" returns 301, and "mydomain.com/about-us/" returns 200, by default - and having the extra redirect isn't good for your search-engine ranking. In other words, simply giving people the URL "/about-us" when the real URL is actually "/about-us/" is not a good idea. Having both URLs work (actually serving the same content from both addresses) also (generally) isn't good for your search engine ranking - search engines may be more forgiving in this case, not sure. It either case, it'll work - but it's not a good idea.

This is part of the reason I perpetuated the discussion, and I'm still not satisfied with the answer...

Isn't good for search-engine ranking? Really? Don't think so.

You would never give or render a url "/about-us" anyway in your site, so what is the problem again? Google won't ever think there's "/about-us" and in case someone enters a link like this it will get redirected (301) to the one with slash.

There's not 2 urls that work, only one. The one without get's redirected.

Never ever seen or heard or experienced any issue with such things regarding search engines or SEO.

Once you start messing around with it, like some with and some without and some that have children have one and pages without don't, will make things difficult changing it will give maybe some problems with search engines.

IMHO this discussion about trailing slash is far from being relevant at all. So I don't need an answer or think there's none. Personal taste and influenced by how you think it should be

[ryan]

Correct me if I'm wrong, but what Google doesn't like are 302s. 301s aren't themselves bad, but can be less helpful to pagerank when stacked. I don't agree with the broad statements of the linked article. A properly used 301 is in fact a great thing for SEO. But also something to be careful with if you want to maximize the value of it.

My experience has been that proper use of 301s is one thing that separates the good SEOs from the unknowing ones. They enable you to relocate URLs in a manner Google will transfer pagerank through. They also enable you to ensure people are always arriving at a consistent URL, thereby making it extremely likely that people will link to you in a consistent manner. Lack of properly used 301s increases the odds of diluted pagerank and duplicate content penalties.

When someone loads domain.com in their browser and it 301s to just www.domain.com (or the opposite), thats a good thing. When someone types www.domain.com/about-us in their browser and it 301s to www.domain.com/about-us/, that's a good thing. When you have an old About Us link at domain.com/page.php?id=123 that 301s to www.domain.com/about-us/, that's a good thing. This is all good for SEO and good for the users. If this is consistent and stays that way, the external links that you build up over time will also be consistent. The pagerank that you accumulate over time will be maximized, not diluted. And what rare external links that point to content at an inconsistent URL will be identified as such by Google while still transferring pagerank.

Where benefit starts getting lost is when you use 301s in a manner that sends it through several paths. My understanding is that Google does dilute pagerank somewhat the more 301s it has to go through in order to meet a request. Example: link points to domain.com/page.php?id=123, which redirects to www.domain.com/page.php?id=123 which redirects to www.domain.com/about-us which then redirects to www.domain.com/about-us/. The user still gets to the right place (good) but the pagerank value of the link that was pointing to domain.com/page.php?id=123 has been diluted to some extent (though don't know how much). Meaning, lost potential, but certainly better than a 404. A smart SEO keeps tabs on this stuff and corrects the first 301 to redirect to the proper URL rather than having to go through further unnecessary 301s. Pagerank potential gets maximized rather than diluted.

The use of a slash vs. non-slash shouldn't be a factor for SEO, so long as it's consistent and 301s to the proper version (excluding root level of course). When someone is advising you to always use trailing slashes, I think this is what they are really saying:

1. Always be consistent in how you link to your own pages (regardless of slash standard). Preventing an unnecessary 301 here reduces the chances of some other 301 getting stacked on top of it. It maximizes the value of the link.

2. Standardizing on a trailing slash reduces the chances of having to implement more 301s later (further reducing the chances of a 301 stack). From an SEO standpoint a trailing slash will scale better because there is no functional reason to ever have to change. Whereas, without a trailing slash there is potential for having to change to one in order to accommodate future growth.

I keep up with SEO stuff, but it's not my full time job either, so someone correct me if any of this has changed.

[Yannick Albert]

On 7.11.2012 at 9:33 PM, Soma said:

Hack no good, tool better:

foreach($templates as $t){
 if($t->name == "admin") continue;
 $t->slashUrls = 0;
 $t->save();
}

 

Done.

 

Since 2.6.9 we can also take care of Page Numbers and URL Segments:

foreach ($templates->find('name!=admin') as $t) {
  if ($t->allowPageNum != 0) $t->slashPageNum = 0;
  if ($t->urlSegments != 0) $t->slashUrlSegments = 0;
  if ($t->slashUrls != 0) $t->slashUrls = 0;
  $t->save();
}

https://processwire.com/api/ref/template/#pw-methods-URLs

In addition, we could also move the conditions into the selector:

 

[anttila]

Funny "bug" is when I disabled slashes from all the templates, there is still / when using httpUrl. Some testers gave warnings when tested a page without / and canonical tells that there should be /. Google respects canonical too. All inbound and inner links linking to /tutorials, not /tutorials/. I used this code to remove last /.

if($id == 1){ $url = "https://timoanttila.com/"; } else { $url = substr($page->httpUrl, 0, -1); }

 

[adrian]

15 minutes ago, tewdin said:

Funny "bug" is when I disable slashes from all the templates, there is still / when using httpUrl. Some testers gave warnings when tested a page without / and canonical tells that there should be /. Google respects canonical too. All inbound and inner links linking to /tutorials, not /tutorials/. I used this code to remove last /.

if($id == 1){ $url = "https://timoanttila.com/"; } else { $url = substr($page->httpUrl, 0, -1); }

 

FYI: https://github.com/processwire/processwire-issues/issues/187

[anttila]

That's awesome. Thanks @adrian!

$url = $page->url(true);