[CONTRIBUTION] Ultimate SEO URLs v2.1 - by Chemo

[douglaswalker]

 

@Hotclutch I have done a search of all my files looking for cpath as opposed to cPath and didn't turn up anything.

Could be a very old link somewhere on the net that is only causing an issue now because i have the SEO script installed.

As far as i can see all is operating correctly and google is picking up all other URL's correctly just this one bad  link.

 

 Webmaster tools just tell me it is a crawl anomaly

 

Can someone let me know if other stores have the same issue if they change cPath to cpath in their URL?

 

 

32 minutes ago, Hotclutch said:

This problem can be replicated with all your category URLs at least. It may only be the one that is reported, but the question is how did google come to discover it. Did you search the addon files for the occurrence of cpath?

[douglaswalker]

ok so i have had a look at access logs and occasionally I am seeing

urls like

/name-of-product-p-42.html?cpath=32

/name-of-product-p-103.html?cpath=23

 

what is that about?

[♥BrockleyJohn]

@douglaswalker I've reproduced it on a couple of sites running this addon

It's not unusual to see garbage urls in the logs - I reckon they are down to faulty spider databases. May not be worth worrying about

[douglaswalker]

16 minutes ago, BrockleyJohn said:

@douglaswalker I've reproduced it on a couple of sites running this addon

It's not unusual to see garbage urls in the logs - I reckon they are down to faulty spider databases. May not be worth worrying about

I always like it when someone with greater knowledge than mine tells me not to worry.

So I am now here in Australia not worrying

[Hotclutch]

5 hours ago, douglaswalker said:

ok so i have had a look at access logs and occasionally I am seeing

urls like

/name-of-product-p-42.html?cpath=32

/name-of-product-p-103.html?cpath=23

 

what is that about?

These are not garbage URLs if they are being crawled by googlebot or MSN.

This is a serious problem that needs to be fixed, because it's a generator of duplicate content. And once it's there it takes forever to clean up.

I don't use this addon, but i would advise not to install it if this is the case. If anyone is interested, they could throw a few of the versions onto a test store to try and determine when this behaviour was introduced.

Edited May 15, 2019 by Hotclutch
typo

[♥BrockleyJohn]

6 hours ago, douglaswalker said:

ok so i have had a look at access logs and occasionally I am seeing

urls like

/name-of-product-p-42.html?cpath=32

/name-of-product-p-103.html?cpath=23

 

what is that about?

There are lots of places where generated links within the code will tack all parameters from the url onto the end, omitting specific ones which might include cPath but obviously won't include cpath.

Thus if you have an inbound link to your site with ?cpath=20 and it gets crawled then it will carry on adding it on the end of any paths that get visited. This is nothing to do with the SEO urls addon, it's how the core code works and will be the case with or without it.

[douglaswalker]

I am seeing the new urls, correctly formatted, beginning to show up in search results.

I only have the one issue in webmaster tools with cpath

 

 

[Hotclutch]

4 minutes ago, douglaswalker said:

I only have the one issue in webmaster tools with cpath

inurl:cpath site:www._____.com.au

[douglaswalker]

15 minutes ago, Hotclutch said:

inurl:cpath site:www._____.com.au

interesting thanks for that

Those are the old URLs with the correct cPath that haven't been dropped yet. The new urls are in the process of showing up

 

Edited May 15, 2019 by douglaswalker
misunderstood but no get it

[Hotclutch]

The point i am trying to make is that you have both cpath and cPath in your indexed URLs, and this is not normal. Maybe you had it before you installed SEO URLs - i don't know - core osCommerce does not do that. Maybe you installed something else that introduced that paramter cpath.

[douglaswalker]

 

Ahh i see what you mean

i missed that

it looks like it is happening with the reviews

run-pr-103.html?page=2&cpath=23

soldier-pr-282.html?cpath=23

very puzzled now

[Jack_mcs]

@douglaswalkerThe problem is that the url's are coming from outside of the shop, from what you have posted. So changing code in the shop is the wrong approach, in my opinion. I suggest at least one of the following:

• Use googles parameter blocking tool. It is case-sensitive so be sure to use lowercase cpath when adding it.
• The above only affects google. To apply to all search engines, add redirect code in the roots .htaccess file to change all instances of  cpath to cPath.
• Edit the application_top file and add code to replace cpath with cPath.

[♥BrockleyJohn]

what he said - except that it's redirecting a url back to itself in a loop which is a feature best left unsupported. I'm looking at suppressing the redirect if the redirect url is the same as the one you started with.

[douglaswalker]

@Jack_mcs thank-you

so would i just add cpath

I can see in the console that cPath is already listed as not changing content (this was google that put that there not me)

There are warnings everywhere about changing things

19 minutes ago, Jack_mcs said:

Edit the application_top file and add code to replace cpath with cPath.

How would i do this

@BrockleyJohn

Do you mean you are working out a way to stop the issue 

2 hours ago, BrockleyJohn said:

I've reproduced it on a couple of sites running this addon

Really appreciate all the help guys

[Hotclutch]

i suggest that you don't add cpath as a parameter for google to ignore.

It's better to let google crawl all those URLs and redirect to the proper format.

 

[Jack_mcs]

9 hours ago, douglaswalker said:

I can see in the console that cPath is already listed as not changing content (this was google that put that there not me)

I mentioned adding cpath,  not cPath. cPath is a valid name and google will add it as it is found. It should be set to let them decide.  But cpath is invalid and you are wanting to stop them so adding it is fine.

9 hours ago, douglaswalker said:

How would i do this

In includes/application_top.php

  if (isset($_GET['cPath'])) {

replace with

  if (isset($_GET['cPath']) || isset($_GET['cpath'])) {
    if (isset($_GET['cpath'])) $_GET['cPath'] = $_GET['cpath'];

I haven't test the above but I think it will work.

The best fix is to find out where the links are coming from. Even if you get all of this to work, what if a link shows up for products that uses Products_id instead of products_id?

[douglaswalker]

1 hour ago, Jack_mcs said:

if (isset($_GET['cPath']) || isset($_GET['cpath'])) { if (isset($_GET['cpath'])) $_GET['cPath'] = $_GET['cpath'];

Hi there

I tried the above in application top and then tested the incorrect link eg cpath instead of cPath

I still just got the page trying to redirect and finally fail.

[Hotclutch]

3 hours ago, Jack_mcs said:

The best fix is to find out where the links are coming from. Even if you get all of this to work, what if a link shows up for products that uses Products_id instead of products_id?

I think code was introduced (unknowingly) that used cpath instead of the proper cPath, and subsequently removed / deactivated, that's why a search reveals nothing. Could have been anything like a poorly coded HT module that caused this.

[Jack_mcs]

@douglaswalker Try this. In inludes/application_top,.php, find

  require('includes/functions/html_output.php');

add beneath

  if (strpos($_SERVER['REQUEST_URI'], "cpath") !== FALSE ){
    $_SERVER['REQUEST_URI'] = str_replace('cpath', 'cPath', $_SERVER['REQUEST_URI']);
    $location = "https://YOUR DOMAIN" . $_SERVER['REQUEST_URI'];
    header("HTTP/1.0 301 Moved Permanently"); 
    header("Location: $location");  
  }

If that doesn't work, it would require being able to work with the code and that is probably not worth the effort if it is just one url, especially if it is as @Hotclutch mentioned.

[douglaswalker]

@Jack_Mcs

thank-you that certainly worked.

Should I also place cpath lowercase for google to ignore?

 

[Jack_mcs]

It's not needed since the code will issue a 301 if they try to visit such a link. If the original problem isn't fixed and they keep getting a url with the lower case, they will probably complain about it.

[douglaswalker]

Hi there

I am using this contribution and I am trying to 301 redirect an old product I no longer stock to a new one.

like this in htaccess

redirect 301 /product-p-800.html https://www.site.com/product-p-900.html

 

however i am finding that it will not work anymore.

Is there a different way i have to do a permanent redirect on a product when SEO urls is implemented or have  I totally missed something

 

[Hotclutch]

the syntax should be like this:

Redirect 301 /old-product-p-23.html /new-product-p-24.html

put it at the bottom of the rules.

[douglaswalker]

@Hotclutch

hi there

unfortunately it results in this...

name-of-product-p-40.html?products_id=33

A similar issue is here

https://www.oscommerce.com/forums/topic/408028-301-redirects-and-seo-urls/

to do with category redirects

[Hotclutch]

The URL (product) you are trying to redirect has been deleted, or still exists in the database?

What i gave should work for the former case, not sure what to suggest if you have the latter scenario.