301 Redirect Question

[InvincibleRecordings]

We have old 301 Redirects would like to remove from the .htaccess file on our server. My question is does MIVA create any of these? I noticed that we are using the URIs tab in our products to set the path. I do not want to erase anything in the .htaccess file that could break our site.

[ILoveHostasaurus]

If the statements are actual "Redirect" or "RedirectPermanent" statements, then there's a high likelihood that you can attach those as additional URI's to the target products, categories, etc. in the store's URI Management, with the option set to redirect 301 to the canonical URL; that's if you still care about having the redirect at all. They would not have been put there by the software.

If the redirection is using Rewrite statements, and/or involves query strings, those may not be something URI management can handle; we'd have to take a look in that case.

[InvincibleRecordings]

Thanks for the details. My question is pretty simple which I think you answered but I would like to make sure. So NO redirects that I see in my .htaccess file are being created by the MIVA admin software?

[ILoveHostasaurus]

That is correct. Various versions of Miva Merchant will potentially add rewrite rules, pointing at either merchant.mvc or uri.mvc, but no version has ever added redirect statements.

[jsdva]

So, if we have old redirects that we want to move into URI Management, we go to URI Management >> URIs, click the Add URI(s) button and add them that way? Even thought they do not currently exist in Miva? For example, you can add an old category, such as /category/old-page.html as the URI and destination is the new category with the redirect that you want?

I feel like I'm flying blind. I really liked being able to manage it all from the htaccess file of my own creation ... but I know that is not easiest for all.

Jamie

[ILoveHostasaurus]

Correct, so if /category/old-page.html was what used to point to the no longer in existence 'old-page' category, and now the category 'new-page' has replaced it, you probably had something like:

RedirectPermanent /category/old-page.html http://domain.com/category/new-page.html

Now, you can instead go to the new-page category in the store, URI's, add /category/old-page.html as a 301-redirect to canonical URL, and if anyone hits the old link, they'll be redirected just like htaccess would have done.

Keep in mind that every entry in a htaccess file has to be compared to a new request, for every single request, unless a rule is hit that instructs the server to stop further processing. The more redirects and rewrites that are present, the more work the web server has to do on every request, so having a Redirect or Rewrite whose only purpose is to 301 an old URL that gets requested once a month, adds performance impact for the other ten million requests per month that do not need redirection. Getting it out of there and into URI management will eliminate that issue, or at least some of it if all but necessary rules have been removed.

[jsdva]

Correct, so if /category/old-page.html was what used to point to the no longer in existence 'old-page' category, and now the category 'new-page' has replaced it, you probably had something like:

RedirectPermanent /category/old-page.html http://domain.com/category/new-page.html

Now, you can instead go to the new-page category in the store, URI's, add /category/old-page.html as a 301-redirect to canonical URL, and if anyone hits the old link, they'll be redirected just like htaccess would have done.

Keep in mind that every entry in a htaccess file has to be compared to a new request, for every single request, unless a rule is hit that instructs the server to stop further processing. The more redirects and rewrites that are present, the more work the web server has to do on every request, so having a Redirect or Rewrite whose only purpose is to 301 an old URL that gets requested once a month, adds performance impact for the other ten million requests per month that do not need redirection. Getting it out of there and into URI management will eliminate that issue, or at least some of it if all but necessary rules have been removed.

So for the redirect, I do it on the Edit Category: New Category screen > URI, and not in URI Management >> URIs? Just want to make sure I know where to do this.

Understood about the server requests.

Thanks!

Jamie

[ILoveHostasaurus]

You can do it in either location, but I find it easier at the new cat/prod level for a one-off, or the central area for bulk adding if you have them all handy. Under URI management you can + to add a new one, type it in, select the store, set the destination type and code, pick 301. At the new cat level, you'd click +, select 301, type the URI.

[jsdva]

You can do it in either location, but I find it easier at the new cat/prod level for a one-off, or the central area for bulk adding if you have them all handy. Under URI management you can + to add a new one, type it in, select the store, set the destination type and code, pick 301. At the new cat level, you'd click +, select 301, type the URI.

Excellent! Thank you David! That's what I needed to know.

Jamie

[Jim Cockerham]

What's the best practice for 301's when you eliminate a child category? For example with facets I no longer need many child categories. Should they be redirected to the parent, which is where the products now reside?

[lesliekirk]

I must be doing something wrong because if I try to use the URI Management to redirect a category (or product) that is not longer available, I still wind up having a live long-style link that the spiders are finding. How do I prevent that from happening? The category (or product) must remain live for the URI Management to function. But it no longer has a canonical URI.

[Jim Cockerham]

I must be doing something wrong because if I try to use the URI Management to redirect a category (or product) that is not longer available, I still wind up having a live long-style link that the spiders are finding. How do I prevent that from happening? The category (or product) must remain live for the URI Management to function. But it no longer has a canonical URI.

I'm not 100% sure on this because I am just doing this today but I can tell you that I set all of my old child categories to inactive and then 301 them to their parent category and it seems to be working fine. I don't think you need to keep them active.

[lesliekirk]

I'm not 100% sure on this because I am just doing this today but I can tell you that I set all of my old child categories to inactive and then 301 them to their parent category and it seems to be working fine. I don't think you need to keep them active.

Jim thanks. I'm going to do a test of a handful of URIs. These are actually products that have been redirected to categories.