I have site that has many links to its pages. And I will completely renew site, update CMS, content and page structure. Domain remains the same.
What will get users in browser if they find somewhere on the Internet old link
to old sites page and follow by that link while it's already a new site and
old page where link leads to doesn't exist?
How to make a redirect or something from these old links if old
pages not open to root of domain?
What's about Google in that case how do not lost PR and
redirect that PR weight of old pages to main domain?
I am kindly appreciate any relative discussion on this topic because it's really interesting from all sides.
What will get users in browser if they find somewhere on the Internet old link to old sites page and follow by that link while it's already a new site and old page where link leads to doesn't exist?
They will get a 404 Not Found.
How to make a redirect or something from these old links if old pages not open to root of domain?
You'll need to create a 301 redirect from every old page to the equivalent new page. You can do it using mod_alias:
RedirectMatch 301 ^/old_page/(.*)$ /new_page/$1
or mod_rewrite:
RewriteRule ^old_page/(.*)$ /new_page/$1 [L,R=301]
You'll obviously need to tailor the matching expressions and targets to your specific needs. If you have a lot of individual URL's that need redirecting, you may want to look into creating a RewriteMap.
What's about Google in that case how do not lost PR and redirect that PR weight of old pages to main domain?
As long as you use 301 redirects (a permanent redirect, as opposed to 302, a temporary redirect) Google's page ranking will transfer to the new URL.
What's better to use mod_alias or mod_rewrite in this situation and why?
Either is fine, but mod_rewrite gives you a lot more options and allows for rewrite maps. But if you are doing something simple, mod_alias is fine.
Again the same with 301 and 302 what's better to use here?
You want 301 here. It means "the resource that you requested has permanently moved to HERE" as opposed to a 302 which means "the resource that you requested isn't here right now, but in the mean time, you can find it HERE". Also, Google won't transfer any page ranking to the new page if you only do a 302 redirect, since it's meant only for temporary redirects. Not when a page has permanently moved to a new URL.
And the last I just looked on the old pages they all like domain.tld/index.php?id=77 does this rule correct RewriteRule ^index.php?id=(*)$ / [L,R=301] in that case for any id number to root?
This rule will not work. You cannot match against the query string (the ?id= part) in a RewriteRule, only against the %{QUERY_STRING} var in aRewriteCond. Also(*)` is probably not what you want.
This will 301 redirect any request for /index.php?id=N where N is any number, to the document root.
RewriteCond %{QUERY_STRING} ^id=([0-9]+)
RewriteRule ^index.php$ / [L,R=301]
Related
While updating a website (completely new page tree, IDs have changed), the old links need to redirect to the new links. Domain stays the same.
This is the first thing I write in my .htaccess
RewriteEngine on
Redirect 301 /index.php?id=5 /contact
Redirect 301 /test.html /xy.html
Redirect 301 /index.php?id=6 /imprint
# and many more
test.html successfully links to xy.html (just a test, they don't even exist and correctly show the 404 page)
the index.php?id=x redirects however do not work. They actually still open whatever new page has this ID.
I don't understand why it's not working. Is TYPO3 interfering? I though I would be safe if I write it as the first thing in my .htaccess.
TYPO3 does not interfere as the rules in the .htaccess file are evaluated before.
Another option could be to use the redirect module of TYPO3 for creating the redirects. Those can then be created in the backend and maintained by editors. A small drawback is that performance is not that perfect as in .htaccess but it is much more convenient.
My old website is located in public_html. I have a new version of the site, which i installed in public_html/new/ .
I want to redirect all traffic from https://example.com to https:/example.com/new but i want to allow users to browse the old version (https://example.com) if they click a link from my new site.
Tried using:
RewriteCond %{HTTP_REFERER} !^https://example.com/.*
to match the referrer, but it doesn't seem to work.
Any help would be much appreciated.
RewriteEngine On RewriteCond %{HTTP_REFERER} !^https://example.com/.*
​RewriteRule ^$ https://example.com/new/? [R=301,L]
You've implemented this as a 301 (permanent) redirect (as it would need to be for SEO if you are migrating from an old to new site). However, the 301 redirect will be cached persistently by the browser. And redirect the user back to /new (from cache) without making a request to the server.
(This redirect also only redirects the old homepage. Inner pages are not redirected. Is that the intention?)
This would need to be a 302 (temporary) redirect - to avoid the redirect being cached, but that's not so good for SEO.
You could include a ?noredirect=1 parameter on URLs back to the old site (in the root) - a different URL - and only redirect when this param is not present. However, you would need to persist this URL param across all URLs having navigated from the new to old site. (And would allow anyone to access the old site by simply appending this URL param.)
However, #CBroe's suggestion in comments would be preferable. To move the old site to an /old subdirectory and the new site replaces the old site in the root. This would be better for SEO and users. Optionally, you could then simply block access to /old if the Referer is not the same domain (which would allow links from the new to old). And would prevent (most) bots from accessing /old (although you would still implement a X-Robots-Tag: noindex HTTP response header). Note, however, the Referer is unreliable and might not be set at all by some browsers (user's settings).
I am using RewriteCond %{HTTP_HOST} ^(www\.)?oldsite\.com$ [NC]
RewriteRule ^.+$ http://newsite.com%{REQUEST_URI} [L,R=301] to redirect users from one site to another. The root exception in this instance is deliberate; that is, I want visitors to oldsite.com to not be redirected, but visitors to oldsite.com/anypage to be redirected to newsite.com/anypage.
However, when someone manually types in oldsite.com/qwerty (a non-existing page), they (and presumably any search engine) get a 301 redirect and not a 404 error. Is there a rule-based way to avoid this behaviour or do I need to change my .htaccess so that there are individual 301 redirects listed (so that anything else will then give the desired 404 result)?
For simplicity I will refer to "Google" here, but it applies to any search engine.
This is basically a non-issue. The 301 redirects are mostly there to keep your Google ranking from the old domain on the new domain and keep bookmarks valid. If a page existed on the old domain, it should still exist on the new domain.
If someone types a non-existing page on the old domain, the user will see the 404 message on the new domain, but that is okay. Google does not crawl that url. In fact any automated crawler should never encounter that url, so semantics about getting a 301 redirect before a 404 status code does not really apply.
There are two things to look out for:
You had a page on the old domain that now exists under a different name on the new domain. You should add a manual exception for this:
RewriteRule ^mypage$ https://newsite.com/new-page-with-something-fancy [R=301,L]
You had a page on the old domain that no longer exists on the new domain. You should manually add an exception that returns the "Gone" status code
RewriteRule ^i-no-longer-exist$ - [G,L]
There does not really exist a way of checking the status code of the redirected page, unless you go into the land of rewriting to a script that uses something like curl to check the other site, or use something like a proxy. Both are awfully inefficient and hurt your site's ranking more than it could ever gain.
After you've been able to successfully create a url rewrite how do you handle the original and other possibly ways to access a page. This of course to prevent duplicate content. For example if I have this:
RewriteEngine on
RewriteBase /
RewriteRule ^blog/(\d+)/([\w\-/\.]+)/?$ blog.php?id=$1&article_title=$2 [L]
I'm able to access the page by the url
https://www.mysite.com/blog/10/mysite.com (the mysite.com is the article title)
The problem is I'm also able to access the site by going to
https://www.mysite.com/blog.php?id=10article_title=sitetitle
https://www.mysite.com/blog.php?id=10
ect.
How are you supposed to handle those particular urls.
Also should I change the blog.php?id=10 to the rewritten url? Can I rely on something else and just start using the full rewritten url now? The site is new.
For my web site, I have the script that gets called from inside the rewrite detect the URI they were fetched from (using the "REQUEST_URI" variable that at least Apache sets), and redirect to the canonical one if they ever get called with the internal one (outputting a 301 direction).
I am permanently redirecting my website
http://www.oldsite.com
to
http://newsite.com/blog
Is there a difference between using
Redirect 301 / http://newsite.com/blog/
or
RewriteEngine On
RewriteRule ^(.*)$ http://newsite.com/blog/$1 [R=301,L]
Any reason I should use one over the other?
The first uses Apache's internal redirection engine to direct all requests to / to http://newsite.com/blog with a 301 Moved Permanently response code.
The other loads the Apache rewriting engine and rewrites all of the incoming requests that match ^(.*)$ to http://newsite.com/blog/ (appending the matched part of the request URI to the target URI) with a 301 Moved Permanently response code, like the former.
The difference? The former rewrites everything to http://newsite.com/blog/ regardless of the request, and the second takes into account the request URI rewriting it as specified. The first is also somewhat faster than the second because it does not load the rewriting engine, does not introspect the request itself, and (depending on the AllowOverride setting) does not have to look up and load .htaccess files.
I believe the performance difference between the two would be imperceptible to a user.
However, assuming that all of the URLs on the old blog site cleanly map to the new site, then I would recommend using the second method.
If you use the first method, all links to your old blog posts will end up on the home page of your new site, which is not a great experience for users who may have bookmarked links etc.
If you care about SEO, then its the same story, all of your page rank will go from your old blog posts to your new site home page.