<p>I wrote the Retour plugin; it will definitely work. However it only kicks in after 404 error is thrown by Craft. So if some route resolves to the URL in question, it won't kick in (because, by definition, it is then not a 404)</p>

CC BY-SA 3.0
2017-07-14T13:55:30.813Z
If I understand this correctly then, if any part of the original URL matches a any route in Craft then this won't work. So if I have a route in Craft for "products" and the original EE URL is http://domain.com/index.php/ **products**/lipstick/red and redirects to Craft URL http://domain.com/ **products**/makeup/face/lipstick it will not work. Correct?
Wonko
CC BY-SA 3.0
2017-07-15T03:09:37.620Z
No, it would have to match the full route (URI) for it to not throw a 404. Something is wrong on your end I think
andrew.welch
CC BY-SA 3.0
2017-07-15T05:31:55.133Z
OK. It could have been something as innocuous as having a trailing slash on the URL and "exact match" selected. In any case, I did switch things over to where "products" doesn't exist and all seems to be well. But looking back, it probably was exact match and something that trailing slash.
Wonko
CC BY-SA 3.0
2017-07-14T03:51:11.620Z
2017-07-14T03:51:11.620Z
andrew.welch
<p>I would put your redirects at server level if you can (.htaccess),  because you don't necessarily want Craft processing all that traffic when it doesn't need to.</p>

<p>If you put your rule after the Craft rule in your .htaccess it will never fire as everything is routed through index.php before that.</p>

<p>Another potential issue is that Craft inconveniently rename the <code>.htaccess</code> to be <code>htaccess</code> so I would check that too just in case.</p>

<p>If you want to add what you're trying to do in your .htaccess in your answer that would help.</p>

CC BY-SA 3.0
2017-07-15T03:05:20.907Z
Strongly disagree with this. First, if we care about performance, we should not be using `.htacess` at all, as it is parsed at runtime: [Stop using .htaccess files! No, really](https://nystudio107.com/blog/stop-using-htaccess-files-no-really). Secondly, my [Retour](https://github.com/nystudio107/retour) plugin adds very little overhead, it operates only after a 404 has been thrown by Craft.
andrew.welch
CC BY-SA 3.0
2017-07-16T13:36:12.623Z
We want to optimize for the majority case, which is normal requests. Adding to (or even using) .htaccess slows down the majority case of normal requests. Exceptions, such as 404s, rarely happen comparatively speaking, so slowing the entire site down for exceptional cases doesn't make sense imo. At the very least, if you care about performance, eschew .htaccess entirely as per the article, and put them in your server config. Handling exceptions, well, exceptionally, is more effective still imo
andrew.welch
CC BY-SA 3.0
2017-08-02T15:19:11.827Z
In your article, you conclude that it only effects performance when you get into high traffic. High traffic going through both Apache and PHP (and Craft) is probably more of a performance hit for the server and will use more server resources to process a redirect. Until there is further evidence to suggest that it is a benefit RE: time taken, memory & cpu levels on an isolated server doing an identical crawl/task, I don't think you are in a position to say that it is definitely better.
joep
CC BY-SA 3.0
2017-07-14T07:57:23.843Z
2017-07-14T17:44:46.470Z
2017-07-14T17:44:46.470Z
joep
<p>I'm moving a site from EE to Craft. All is well but the redirects from the old URLs to the new do not work.</p>

<p>I have tried:</p>

<ul>
<li>SproutSEO Redirects
(<a href="https://sprout.barrelstrengthdesign.com/craft-plugins/seo/docs/getting-started/redirects" rel="nofollow noreferrer">https://sprout.barrelstrengthdesign.com/craft-plugins/seo/docs/getting-started/redirects</a>) - Results in a Craft 404</li>
<li>Retour (<a href="https://github.com/nystudio107/retour" rel="nofollow noreferrer">https://github.com/nystudio107/retour</a>) - Results in a Craft
404</li>
<li>Reroute (<a href="https://github.com/davist11/craft-reroute" rel="nofollow noreferrer">https://github.com/davist11/craft-reroute</a>) - Results in a
Craft 404</li>
<li>.htaccess redirect - Results in Craft 404</li>
</ul>

<p>The only thing I can think of is that Craft is somehow getting ahead of these solutions and running with the 404.</p>

<p>Any assistance would be appreciated.</p>

<seo><plugin-sproutseo>
301 redirects not working
# 301 redirects not working

(Asked by: username_0 on 2017-07-14)

I'm moving a site from EE to Craft. All is well but the redirects from the old URLs to the new do not work.

I have tried:

* SproutSEO Redirects
  (<https://sprout.barrelstrengthdesign.com/craft-plugins/seo/docs/getting-started/redirects>) - Results in a Craft 404
* Retour (<https://github.com/nystudio107/retour>) - Results in a Craft
  404
* Reroute (<https://github.com/davist11/craft-reroute>) - Results in a
  Craft 404
* .htaccess redirect - Results in Craft 404

The only thing I can think of is that Craft is somehow getting ahead of these solutions and running with the 404.

Any assistance would be appreciated.

**Tags:** seo, plugin-sproutseo


---

## 2 answers

### Answer by username_1 on 2017-07-14. Score: 2 | Accepted answer

I wrote the Retour plugin; it will definitely work. However it only kicks in after 404 error is thrown by Craft. So if some route resolves to the URL in question, it won't kick in (because, by definition, it is then not a 404)

> **Comments:**
> **username_0**: If I understand this correctly then, if any part of the original URL matches a any route in Craft then this won't work. So if I have a route in Craft for "products" and the original EE URL is http://domain.com/index.php/ **products**/lipstick/red and redirects to Craft URL http://domain.com/ **products**/makeup/face/lipstick it will not work. Correct?  
> **username_1**: No, it would have to match the full route (URI) for it to not throw a 404. Something is wrong on your end I think  
> **username_0**: OK. It could have been something as innocuous as having a trailing slash on the URL and "exact match" selected. In any case, I did switch things over to where "products" doesn't exist and all seems to be well. But looking back, it probably was exact match and something that trailing slash.  

---

### Answer by username_2 on 2017-07-14. Score: 0

I would put your redirects at server level if you can (.htaccess), because you don't necessarily want Craft processing all that traffic when it doesn't need to.

If you put your rule after the Craft rule in your .htaccess it will never fire as everything is routed through index.php before that.

Another potential issue is that Craft inconveniently rename the `.htaccess` to be `htaccess` so I would check that too just in case.

If you want to add what you're trying to do in your .htaccess in your answer that would help.

> **Comments:**
> **username_1**: Strongly disagree with this. First, if we care about performance, we should not be using `.htacess` at all, as it is parsed at runtime: [Stop using .htaccess files! No, really](https://nystudio107.com/blog/stop-using-htaccess-files-no-really). Secondly, my [Retour](https://github.com/nystudio107/retour) plugin adds very little overhead, it operates only after a 404 has been thrown by Craft.  
> **username_1**: We want to optimize for the majority case, which is normal requests. Adding to (or even using) .htaccess slows down the majority case of normal requests. Exceptions, such as 404s, rarely happen comparatively speaking, so slowing the entire site down for exceptional cases doesn't make sense imo. At the very least, if you care about performance, eschew .htaccess entirely as per the article, and put them in your server config. Handling exceptions, well, exceptionally, is more effective still imo  
> **username_2**: In your article, you conclude that it only effects performance when you get into high traffic. High traffic going through both Apache and PHP (and Craft) is probably more of a performance hit for the server and will use more server resources to process a redirect. Until there is further evidence to suggest that it is a benefit RE: time taken, memory & cpu levels on an isolated server doing an identical crawl/task, I don't think you are in a position to say that it is definitely better.  

---

