Simple SEO URL (OLD version) [support thread]

[g1smd]

@alicia130

The logic order of the second attempt was correct (page redirect, general non-www redirect, rewrites) but the code could do with some improvements.

The code in the third attempt was much more robust, however it was simply missing

RewriteRule ^cart  http://example.com/ [R=301,L]

or similar, as the very first rule.

Let's take a closer look at that single line of code. Is that very first rule supposed to be "moving" a store from the folder to root?

That code as you have it now would redirect example.com/cart/index.php?parameter=value to example.com/?parameter=value which would cause problems - because the index.php part of the new URL would be missing.

Does it need to preserve the path and/or parameter values in that redirect?

If it does not need to preserve the path and parameters, then changing http://example.com to be http://example.com/? would simply clear the parameter values instead.

If it does need to preserve the path and parameters, there's more detailed code for that in: http://www.zen-cart.com/forum/showth...=150620&page=2 here (which also fixes other issues at the same time too).


Once the user is requesting the correct URL, only then do you attempt to serve the content.

To be clear about the terminology:

Redirects (code with domain name and [R=301,L] in) tell the browser to make a new request for a new URL. The user sees the URL in the URL bar of their browser change.

Rewrites (code with just a server-internal filepath and [L] flag) connect a URL request with a non-default internal filepath to find and serve the page content at the currently requested URL.

[alicia130]

thank you
thank you
thank you

i will take a look at the link right away!

[litepockets]

So recently I have added several categories (and products of course), I cleared and updated cache, but I can't seem to get some of the URLS to form correctly. In webmaster tools I am getting redirect errors such as: (adult content):
Prb #1:
http://www.cupidsbedroom.com/store/index/############/unsorted-############/12-inch-veined-double-dong/anal-toys/beads-balls/anal-love-beads-pink?sort=20a&action=buy_now

Notice the /index/ in the URL. The action=buy_now I believe I may have corrected, we'll see. Also, I should point out that both bold categories above are parent cats, so..???

Prb #2
Categories are also duplicating themselves within the URLs:
http://www.cupidsbedroom.com/store/index/fetish-and-fantasy-clothing/unsorted-fetish-clothing/bra-with-chain/fetish-and-fantasy-clothing/school-girl/2-pc-alley-school-girl-black-tie-top-pleated-skirt-black-plaid-s?sort=20a&action=buy_now

OK, so those are all the redirect errors, not onto the HTTP errors:

Prb #3
http://www.cupidsbedroom.com/store/2...ame-tags?page=gag-gifts-parties-and-novelties-bachelorette-parties-c-67_267&action=sort

The above is URL shows the parent cat and subcat strung together, and has 20a (the sort default), as a "directory". Other similar URLs even have page as a directory..

Perhaps the most confusing of all of this is that I cannot find any internal links on my site at all! For example, for a particular product I see a link as http://www.cupidsbedroom.com/store/a...ittering-probe but in google webmaster tools, the error is showing http://www.cupidsbedroom.com/store/2...=sort&sort=20a


So, naturally, one could only assume that some excludes are messed up, but I cannot spot them. sort & page were just added to the regular exclude list on a wimb for troubleshooting, but were in query excludes since I installed SSU.

Here is the current exclude list in my ssu config:
advanced_search_result,redirect,popup_image_additional,page,download,wordpress,p roduct_reviews_write,popup_image,search_in_description,advanced_search,shopping_ cart,sort,page

Then the query excludes:
zenid,gclid,action,sort,page,disp_order,filter_id,alpha_filter_id,search_in_desc ription,advanced_search,shopping_cart,max_display,number_of_uploads,number_of_do wnloads,currency,keyword

Prb #4
Last but not least... I cannot get 1 stupid category to work correctly.. The category was changed from "Vibrating ###### Toys" to "Vibrators". The cache was cleared and updated, but alas, domain.com/store/vibrators would result in a 404, it would only work when using domain.com/store/vibrators-c-78. BUT, domain.com/store/vibrators/product-name or domain.com/store/vibrators/subcat-name would work!? So I'm still stumped on this one.. Not to mention google is still crawling "vibrating-######-toys" (in addition to) "vibrators"..

One last note, yesterday I used the ssucheck.php file to peek at any possible errors in my .htaccess file, and noticed the trailing / on /store was not there, so I added that. Maybe that will get rid of problem 1, for the /index/ part of it anyways?

PLEASE.. any help? ZC & SSU have been kickin' my booty lately.

site = cupidsbedroom.com/store

[alicia130]

Two questions, both relating to spiders and SSU:

If SSU rewrites the URL from www.mysite.com/index.php?cPath=99
to www.mysite.com/my_category, which one is indexed?

What about old links that could be floating around on the net? If someone clicks on www.mysite.com/index.php?cPath=99 in a google search, when clicked on the URL is re-written to www.mysite.com/my_category. Does this affect page indexing?

We are worried about the same page being indexed multiple ways out there in our great big world wide web.

[g1smd]

If SSU rewrites the URL from www.mysite.com/index.php?cPath=99
to www.mysite.com/my_category, which one is indexed?

If both URL requests return HTTP "200 OK" status then both can be indexed. The Live HTTP Headers extension for Firefox is very useful in checking out the HTTP headers returned by the server.

What a rewrite does, is map an incoming URL request to an internal filepath. So the most crucial part of that is that the links on the page should specify the new URL in the href part of the link. It is those links that *define* the URLs.

What about old links that could be floating around on the net? If someone clicks on www.mysite.com/index.php?cPath=99 in a Google search, when clicked on the URL is re-written to www.mysite.com/my_category.

If the old link still returns "200 OK" it will continue to be indexed. To prevent both URLs being indexed, the old one with parameters should return a 301 redirect to the new URL. This will signal to searchengines that they need to update their index; but the redirect preserves any traffic arriving via the old URL while that is being actioned.

Does this affect page indexing?

We are worried about the same page being indexed multiple ways out there in our great big world wide web.

It certainly does. If both return "200 OK" you'll have problems. If one redirects to the other, Google et. al will eventually sort out what is going on. The redirect is an essential part of the complete system.




To recap. If you have a script inside the server located at the internal filepath /index.php, that script can usually be accessed using the URL example.com/index.php.

If a particular page is returned for the query ?cPath=99 appended to that URL, and it returns HTTP "200 OK" status, then the URL example.com/index.php?cPath=99 can be indexed.

If you install a rewrite such that URL requests for www.mysite.com/my_category are rewritten to fetch content from the server internal filepath at /index.php?cPath=99 and it returns HTTP "200 OK" status, then it too can be indexed.

Pages of the site MUST link to the URL format that you DO want to be indexed and which return "200 OK" status. The URL format that you do not want to be indexed must return either "404 Not Found" or a "301 redirect" to the other URL. The 301 redirect is preferred. It preserves traffic following old, out of date links while signalling to update the URLs listed in the searchengine database.

[alicia130]

HELLLLLLLPPPPPPP!!!!

I have no idea what is going on here. every since I upgraded to version 3.8.3 of SSU, I have been having issues. I have categories that when clicked on, redirect the page to the home page, however the URL stays the same. To fix this issue, I rename the cache folder (they are too large to delete), and copy over the cache folder that was in the download. I then reset the cache using admin->extras->Simple SEO URL manager, and everything works great all links/categories work correctly. After a few hours, the issue pops up again.

Is their a downgrade option to go back to the previous version?!?!?!?!?

[istilah]

Zen 1.38A
SSU 3.8.3

Like VicAvendano, I am experiencing infinite loops when using a "+" in url query parameters like:
http://www..myshop.com/?keyword=bamb...ts_add_product.

You get to such page like this when after a search you directly put things into your cart.

It only happens when there are 2 or more keywords. Use 1 keyword and there is no problem.
It only happens when SSU is on. Turning SSU off and the problem is gone.

So I believe this is a SSU issue, and related to the "+" sign in the string.

Anyone knows how to solve this? I tried to put keyword in the query exclude list, to no success.

Ronald

[konservasi]

I still have long url meanwhile I have install this add on

anyone can help me?

[konservasi]

and when I install the sql I have the error message like here

Warning: require_once(includes/classes/module_installer.php) [function.require-once]: failed to open stream: No such file or directory in /home/konkom/galerigis/admin/ssu.php on line 10

Fatal error: require_once() [function.require]: Failed opening required 'includes/classes/module_installer.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/konkom/galerigis/admin/ssu.php on line 10

[alicia130]

HELLLLLLLPPPPPPP!!!!

I have no idea what is going on here. every since I upgraded to version 3.8.3 of SSU, I have been having issues. I have categories that when clicked on, redirect the page to the home page, however the URL stays the same. To fix this issue, I rename the cache folder (they are too large to delete), and copy over the cache folder that was in the download. I then reset the cache using admin->extras->Simple SEO URL manager, and everything works great all links/categories work correctly. After a few hours, the issue pops up again.

Is their a downgrade option to go back to the previous version?!?!?!?!?

To Yellow:

Going back to a previous version fixed this issue. Something wrong in 3.8.3???