I've deleted products. How do I redirect customers to new ones? or to search instead?

[mprough]

It is because of your url rewrites. You can try putting the redirect after the Ultimate SEO rules, but likely it will leave you with an appended url for the resulting page.

This is one of the many reasons we no longer install urls rewrites.... The very small value does not outweigh the loss of functionality, options and load time lost.

~Melanie

[g1smd]

If you ever use, or intend to use, rewrites in the future (or if any of your other rules found in the .htaccess file use RewriteRule already) change the method slightly.

Instead of using Redirect or RedirectMatch, use RewriteRule with the [R=301,L] flags. It is important that all of your redirect/rewrite code belongs to the same Apache module.

To be clear, RewriteRule comes from Mod_Rewrite and Redirect and RedirectMatch come from Mod_Alias.

Execution order of your directives is controlled NOT by the order the code is listed in your .htaccess file, but by the module execution order within .htaccess.

That is, if Mod_Alias runs before Mod_Rewrite, your Redirect and RedirectMatch directives would be executed before your RewriteRule directives (good!) BUT if Mod_Rewrite runs before Mod_Alias, your RewriteRule directives would be executed before your Redirect and RedirectMatch directives (bad!).

The effect of that would be to expose rewritten filepaths back out onto the web as new URLs, to create unwanted redirection chains, and generally not work as expected.

You don't have control over the module execution order. Your host has set that up. Most get it right, but a few do not.

You can protect yourself from the problem now and in the future by using RewriteRule for all of your directives.

You can also take advantage of the very powerful pattern matching controls that RewriteRule has to offer. Be aware that RewriteRule sees only the 'path' part of the URL. If you need to examine the requested hostname or parameters or the original HTTP request itself, add a preceding RewriteCond to examine the required attribute.

In general,

RewriteRule ^some-pattern  http://www.example.com/somepath [R=301,L]

is the way to go.

If you use rewrites make sure that ALL of your external redirects are listed before the internal filepath rewrites. This is because the redirects send the user to a new URL, and the rewrites 'translate' a URL request into a different internal server filepath. Once the rewrites have executed and are looking on the server's hard drive for the content, it is way too late to be trying to alter the URL the user sees in the browser address bar.

Redirect first so that user sees the right URL. Once the user sees the correct URL, and only then, execute the rewrite to fetch the content.

[mprough]

If you ever use, or intend to use, rewrites in the future (or if any of your other rules found in the .htaccess file use RewriteRule already) change the method slightly.

Instead of using Redirect or RedirectMatch, use RewriteRule with the [R=301,L] flags. It is important that all of your redirect/rewrite code belongs to the same Apache module.

To be clear, RewriteRule comes from Mod_Rewrite and Redirect and RedirectMatch come from Mod_Alias.

Execution order of your directives is controlled NOT by the order the code is listed in your .htaccess file, but by the module execution order within .htaccess.

That is, if Mod_Alias runs before Mod_Rewrite, your Redirect and RedirectMatch directives would be executed before your RewriteRule directives (good!) BUT if Mod_Rewrite runs before Mod_Alias, your RewriteRule directives would be executed before your Redirect and RedirectMatch directives (bad!).

The effect of that would be to expose rewritten filepaths back out onto the web as new URLs, to create unwanted redirection chains, and generally not work as expected.

You don't have control over the module execution order. Your host has set that up. Most get it right, but a few do not.

You can protect yourself from the problem now and in the future by using RewriteRule for all of your directives.

You can also take advantage of the very powerful pattern matching controls that RewriteRule has to offer. Be aware that RewriteRule sees only the 'path' part of the URL. If you need to examine the requested hostname or parameters or the original HTTP request itself, add a preceding RewriteCond to examine the required attribute.

In general,

RewriteRule ^some-pattern  http://www.example.com/somepath [R=301,L]

is the way to go.

If you use rewrites make sure that ALL of your redirects are listed before those. This is because the redirects send the user to a new URL, and rewrites 'translate' a URL request into a different internal server filepath. Once rewrites have executed and are looking on the server's hard drive for the content it is way too late to be trying to alter the URL the user sees in the browser address bar.

Redirect first so that user sees the right URL. Once the user sees the correct URL, and only then, execute the rewrite to fetch the content.

Unfortunately, even this method will produce a resulting url which is appended with a ? or ?string because of USEO. A good friend of mine in the UK and I worked very hard to accomplish this, and we did for a site which was changing platforms.... But trust me it was no easy task and surely not clean as we had to also strip the appended strings caused by USEO. It was many many lines of syntax as we could not grab a query string to batch any of them and sanitize them as well.

Best solution is to avoid SEO rewrites for your Zen Cart. Changing product titles changes and loses the indexed urls. Rewrites and redirects for anything are nearly impossible and the load speed is diminished somewhat as well.

If there were a cleaner solution, then sure rewrite them... But I have tested them all and the only one I think is close is Ceon. The rest all have some or all of the functionality issues above.

~Melanie

[DML73]

It is because of your url rewrites. You can try putting the redirect after the Ultimate SEO rules, but likely it will leave you with an appended url for the resulting page.

This is one of the many reasons we no longer install urls rewrites.... The very small value does not outweigh the loss of functionality, options and load time lost.

~Melanie

Im not using any of the URL rewrite modules and have never done. My .htaccess file looks like this:
----------------------
<Files 403.shtml>
order allow,deny
allow from all
</Files>

# redirects any URL that includes: record_company.php/password_forgotten.php this is a security patch
RedirectMatch Permanent ^/(.*[record_company.php]+)/(password_forgotten.php)$ /page_not_found.php

# redirects any URL that includes: /images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RedirectMatch Permanent ^/(.*[images]+)/(wp-.*\.php)$ /page_not_found.php


redirect 301 /index.php?main_page=product_info&cPath=5&products_id=38 http://www.example.com/


ErrorDocument 404 /index.php?main_page=page_not_found

RewriteEngine On

# Index Redirect for /index.(html?|php) with no parameters
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(html?|php)\ HTTP/
RewriteRule ^index\.(html?|php)$ http://www.example.com/? [R=301,L]

# Canonical Redirect non-www and/or appended port number to www [EXCLUDE /admin requests]
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
----------------------------

The redirect 301 /index.php?main_page=product_info&cPath=5&products_id=38 http://www.example.com/
does not redirect to http://www.example.com/ when I go to /index.php?main_page=product_info&cPath=5&products_id=38

Do you see anything Im doing wrong?

[g1smd]

Yes, there are a lot of problems. My earlier post (above) covers most of those. In summary.

Change all of the "Redirect" and "RedirectMatch" rules to use RewriteRule with [R=301,L] flags, and list those before all of your other rules.

You'll need to look at QUERY_STRING using a RewriteCond too.

The .* construct in your code is VERY inefficient. If it is meant to match none, one, or multiple folder levels, use something like (([^/]+)/*) instead. It will run hundreds of times faster. The new pattern means (("not a slash" one or more times), followed by slash) the whole of that "zero or more times").

[record_company.php] matches any single letter from the list r e c o r d _ m p a n y h and the + says "one or more times", so a request for "drocer_ynapmoc.hph" or for "cordpan" would also fulfill the pattern. The brackets aren't needed at all. You need to match the literal "record_company.php" not a list of letters.

[g1smd]

... and make sure you add the [L] flag to the end of every rule.

[DML73]

Yes, there are a lot of problems. My earlier post (above) covers most of those. In summary.

Change all of the "Redirect" and "RedirectMatch" rules to use RewriteRule with [R=301,L] flags, and list those before all of your other rules.

You'll need to look at QUERY_STRING using a RewriteCond too.

The .* construct in your code is VERY inefficient. If it is meant to match none, one, or multiple folder levels, use something like (([^/]+)/*) instead. It will run hundreds of times faster. The new pattern means (("not a slash" one or more times), followed by slash) the whole of that "zero or more times").

[record_company.php] matches any single letter from the list r e c o r d _ m p a n y h and the + says "one or more times", so a request for "drocer_ynapmoc.hph" or for "cordpan" would also fulfill the pattern. The brackets aren't needed at all. You need to match the literal "record_company.php" not a list of letters.

Wow..thanks for the info, ... with my limited knowledge of .htaccess files I will need to re-read your comments a few times

[g1smd]

This is Server Configuration Code, so YOU need to know exactly how it works so that YOU can maintain it as your site evolves. Use the Mod_Rewrite documentation at apache.org for guidance as well as the examples here.

One simple typo can bring your whole site down (if you are lucky) or slowly and silently erode your search listings until the fault puts you and your site out of business. So, be sure you know what every line of code does and why it is there.

Make sure that every block of code has # comments explaining exactly what it does. You'll thank yourself six months later.

[DML73]

Ok, to correct the RewriteRule I did the following:

RewriteEngine On

# Index Redirect for /index.(html?|php) with no parameters
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(html?|php)\ HTTP/
RewriteRule ^index\.(html?|php)$ http://www.example.com/? [R=301,L]

# Canonical Redirect non-www and/or appended port number to www [EXCLUDE /admin requests]
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

#Redirects product page 187 to index
RewriteRule ^index.php?main_page=product_info&cPath=65&products_id=187 http://www.example.com/ [R=301,L]

But the redirect rule for product page 187 still isnt redirecting. What am I doing wrong?

[g1smd]

RewriteRule cannot 'see' query string data. It only sees the 'path part' of a URL, following the initial slash, up until the question mark.

Use a preceding RewriteCond testing %{QUERY_STRING} to see the parameter data, in the same way others have looked at THE_REQUEST and HTTP_HOST and REQUEST_URI.

Clear those parameters with a trailing question mark on the end of the target URL to stop them being re-appended.

Make sure that the most 'specific' rule is listed FIRST, otherwise you risk creating an unwanted 'redirection chain' for non-www requests.