douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 @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? Quote Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 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? Quote Link to comment Share on other sites More sharing options...
♥BrockleyJohn Posted May 15, 2019 Share Posted May 15, 2019 @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 1 Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 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 Smoky Barnable 1 Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 15, 2019 Share Posted May 15, 2019 (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 May 15, 2019 by Hotclutch typo Quote Link to comment Share on other sites More sharing options...
♥BrockleyJohn Posted May 15, 2019 Share Posted May 15, 2019 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. Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 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 Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 15, 2019 Share Posted May 15, 2019 4 minutes ago, douglaswalker said: I only have the one issue in webmaster tools with cpath inurl:cpath site:www._____.com.au Quote Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 (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 May 15, 2019 by douglaswalker misunderstood but no get it Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 15, 2019 Share Posted May 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 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 Quote Link to comment Share on other sites More sharing options...
Jack_mcs Posted May 15, 2019 Share Posted May 15, 2019 @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. Quote Support Links: For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc. Get the latest versions of my addons Recommended SEO Addons Link to comment Share on other sites More sharing options...
♥BrockleyJohn Posted May 15, 2019 Share Posted May 15, 2019 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. Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
douglaswalker Posted May 15, 2019 Share Posted May 15, 2019 @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 Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 15, 2019 Share Posted May 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Jack_mcs Posted May 16, 2019 Share Posted May 16, 2019 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? Quote Support Links: For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc. Get the latest versions of my addons Recommended SEO Addons Link to comment Share on other sites More sharing options...
douglaswalker Posted May 16, 2019 Share Posted May 16, 2019 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. Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 16, 2019 Share Posted May 16, 2019 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. Quote Link to comment Share on other sites More sharing options...
Jack_mcs Posted May 16, 2019 Share Posted May 16, 2019 @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. Quote Support Links: For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc. Get the latest versions of my addons Recommended SEO Addons Link to comment Share on other sites More sharing options...
douglaswalker Posted May 16, 2019 Share Posted May 16, 2019 @Jack_Mcs thank-you that certainly worked. Should I also place cpath lowercase for google to ignore? Quote Link to comment Share on other sites More sharing options...
Jack_mcs Posted May 16, 2019 Share Posted May 16, 2019 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. Quote Support Links: For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc. Get the latest versions of my addons Recommended SEO Addons Link to comment Share on other sites More sharing options...
douglaswalker Posted May 25, 2019 Share Posted May 25, 2019 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 Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 25, 2019 Share Posted May 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
douglaswalker Posted May 25, 2019 Share Posted May 25, 2019 @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 Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted May 25, 2019 Share Posted May 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.