Jump to content
simona6

How do you enforce no trailing slash, on homepage only?

Recommended Posts

A Wordpress website has trailing slashes, and all is fine.  But for some reason SEO software sees the homepage with and without the /.  Causing duplication.

Not all SEO software sees it.

What is the HTACCESS code to add, to enforce, only on the homepage main domain URL, NO trailing slash?

Thanks

 

Share this post


Link to post
Share on other sites

By homepage, are you talking about the root of the domain? example.com, and not like example.com/homepage?

Technically there is always a trailing slash for domain roots. Because it's not a trailing slash per se but rather a leading slash. And you cannot get rid of a leading slash - example.com and example.com/ are the exact same thing.

What exactly is the software saying?

Share this post


Link to post
Share on other sites

It's saying we have duplicate Title Tags, for the normal and / version of the same page.

Share this post


Link to post
Share on other sites

The "normal" and "/ version" are the same thing.

Duplicate title tags sounds like it means duplicate <title> tags. Check your HTML markup.

Share this post


Link to post
Share on other sites

"DUPLICATED VALUES TITLE TAGS"

For / and non-slash.

Share this post


Link to post
Share on other sites

I think those SEO plugins tend to cause more confusion than they add value. I have personally never used them, and I do not care if some of my title tags are too long, duplicated, or if my descriptions are too short. If some of my descriptions are short, then it is probably intentionally, and I do not want notifications about it.

Having said that, chances are that you can enter in:

https://example.com./

With a "dot" in front of the slash, this is also a useful trick to circumvent certain cookie-walls on websites. I think very few websites seem to normalize such requests, since developers are often not aware of it. Afaik. Search engines will perceive it just the same — dot or no dot.. But, I still prefer to redirect such requests. 

I think requinix is correct. Even if a misbehaving client leaves out the path part in a HTTP request, a leading slash will, as a minimum, be "presumed" by the server. But, I am not sure about that, or if it is even possible to forge such a request. Normally, the client should always add a leading slash, since an empty path is not valid.

See this: http://tools.ietf.org/html/rfc7230#section-5.3.1

I have also encountered SEO folks/software that erroneously claimed you could not use multiple h1 headings, needed to include keywords meta, and so on.. But that is another story...

The same goes for <a href=""> links basically. It has absolutely no significance if we include the slash or leave it out on the bare domain name. 

Another configuration flaw that most websites seem to suffer from, is the fact that we can use non-existent URL parameters. I.e. ?something=blah; ideally, doing that should simply result in a 404 error — I do not think these SEO plugins will inform you about these niche cases. Regardless, Google is quite good at choosing the canonical URL, so I will not worry too much about it, unless I start having problems — start seeing the main pages de-indexed, and the bugged pages taking their place.

Another thing to keep in mind is that we also need to whitelist certain parameters, such as ?fbclid, since we might accidentally block people from sharing links on Facebook, and other social media sites.

Personally, I prefer leaving out trailing slashes on article pages and files, since they indicate directory or index rather than a page; but it really does not matter; IMHO, it is just ugly to see URLs like this:

https://www.example.com/some-article-name/
https://www.example.com/robots.txt/

 

Share this post


Link to post
Share on other sites
39 minutes ago, JacobSeated said:

Even if a misbehaving client leaves out the path part in a HTTP request, a leading slash will, as a minimum, be "presumed" by the server. But, I am not sure about that, or if it is even possible to forge such a request. Normally, the client should always add a leading slash, since an empty path is not valid.

The client must send the slash at a minimum. Not submitting anything is a gross violation of the HTTP standard.

"Forging a request" is as simple as

1. Typing the request out into some editor, then copying it all
2. Using telnet to connect to the web server
3. Pasting the request, remembering to include two newlines at the end if you're sending a request without a body

The copy/paste is because web servers want requests quickly and you won't be able to type it out yourself fast enough before they close the connection.

Forge a request that starts with "GET HTTP/1.1" (ie, the first line without the resource URI) to any website and you'll get a 400.

 

39 minutes ago, JacobSeated said:

I have also encountered SEO folks/software that erroneously claimed you could not use multiple h1 headings, needed to include keywords meta, and so on.. But that is another story...

Should not. But search engines are generally smart enough to recognize the difference between a site's branding H1 and some sidebar's H1 and the content H1. So the guideline is more about not using multiple H1s for a distinct section of the page.

 

39 minutes ago, JacobSeated said:

Regardless, Google is quite good at choosing the canonical URL, so I will not worry too much about it, unless I start having problems — start seeing the main pages de-indexed, and the bugged pages taking their place.

Google basically picks what is most popular, not necessarily what is correct.

But if you have multiple URLs to the same page with the same content then you will be penalized for it. So deal with it sooner rather than later.

 

39 minutes ago, JacobSeated said:

Personally, I prefer leaving out trailing slashes on article pages and files, since they indicate directory or index rather than a page; but it really does not matter; IMHO, it is just ugly to see URLs like this:


https://www.example.com/some-article-name/
https://www.example.com/robots.txt/

 

Trailing slashes on files are dumb. Fortunately it's rare to see anyone do that.

Trailing slashes on everything else is up to personal/business preference. (Personally, I don't like slashes on pages either. With exceptions.)

  • Great Answer 1

Share this post


Link to post
Share on other sites

I used h1's in my section elements for a while a few years back, on my tutorial site, without noticing any negative effect on my traffic. I changed back to h2-h6+section when it was made known that some assistive tech did not support it yet, and also the document outline go messed up since browsers also did not support it. I still hope that it is implemented, but I guess I have no real use for it right now.

Interesting you actually tried doing that and it resulted in a 400 error. I was wondering about how to test that.
 

Share this post


Link to post
Share on other sites
7 hours ago, JacobSeated said:

Interesting you actually tried doing that and it resulted in a 400 error. I was wondering about how to test that.

HTTP/1 is all text. You can totally run requests and get responses yourself. SSL makes the tooling a little harder because you have to connect using an SSL client, but still not too hard.

GET / HTTP/1.1
Host: forums.phpfreaks.com
Connection: close

HTTP/1.1 301 Moved Permanently
Server: nginx/1.16.0
Date: Sun, 26 Jul 2020 18:35:57 GMT
Content-Type: text/html
Content-Length: 169
Connection: close
Location: https://forums.phpfreaks.com/

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.16.0</center>
</body>
</html>

HTTP/2 uses binary, but otherwise the structure is about the same so I assume there are clients that can convert to it for you.

Share this post


Link to post
Share on other sites

...it took me years to realize the best websites -- the ones on "page one of google" -- almost universally break every "SEO" rule, have the worst, most improperly formatted html, duplicate content, errors up the wazoo.... heck, if it were me, nowadays, and I wanted to be on page one of google, I would intentionally violate every SEO rule. Go ahead, check it out.... look at the top sites on google, NONE of them follow any rules! Then.... go to page 50 on google, and you'll find all the perfect "no errors" websites, with perfect un-duplicated titles, perfect html, pure as the driven snow. Page 50.

Edited by StevenOliver

Share this post


Link to post
Share on other sites
35 minutes ago, StevenOliver said:

...it took me years to realize the best websites -- the ones on "page one of google" -- almost universally break every "SEO" rule, have the worst, most improperly formatted html, duplicate content, errors up the wazoo.... heck, if it were me, nowadays, and I wanted to be on page one of google, I would intentionally violate every SEO rule. Go ahead, check it out.... look at the top sites on google, NONE of them follow any rules! Then.... go to page 50 on google, and you'll find all the perfect "no errors" websites, with perfect un-duplicated titles, perfect html, pure as the driven snow. Page 50.

The "best websites" aren't on the first page because they follow the standard rules of SEO. It's because they're popular. They're long past the first date so they don't have to wear fancy suits and nice dresses anymore.

You do not know better than the experts. Get vaccinations, wear a mask, and follow good SEO principles.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.