Jump to content
spidometrs

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

Recommended Posts

 

@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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

@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


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE).

here: https://github.com/gburton/Responsive-osCommerce/releases

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Hotclutch
typo

Share this post


Link to post
Share on other sites
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.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE).

here: https://github.com/gburton/Responsive-osCommerce/releases

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
4 minutes ago, douglaswalker said:

I only have the one issue in webmaster tools with cpath

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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by douglaswalker
misunderstood but no get it

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE).

here: https://github.com/gburton/Responsive-osCommerce/releases

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@Jack_Mcs

thank-you that certainly worked.

Should I also place cpath lowercase for google to ignore?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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

×