Redirects

[tylerfraser]

Hello,

My question is: how important is it to wait for the a redirect to get seen and cached before you take down the old page?

More in depth: my old platform has seriously limited my ability to add sitemaps and make edits to htacces. I just want to change nameservers (which will delete everything on there) and upload the htaccess is that alright?

Another way of saying it: when redirecting a page, is it necessary for google to see the old page before it is deleted?

Thanks

Tyler

[RyanKent]

when redirecting a page, is it necessary for google to see the old page before it is deleted?

If you are performing the redirect via htaccess, then no. A 301 redirect is simply a header code. It lets Google know the page which is being displayed is not the page requested, but a different URL. Google then understands the need to replace the old URL with the new one.

[tylerfraser]

The fine people at bruce clay said it's important to let the page be seen before deleting it.

[RyanKent]

The fine people at bruce clay said it's important to let the page be seen before deleting it.

Do you have a specific link? Something is wrong with that statement and I feel it must be taken out of context.

Or possibly there is additional details you have not shared? Has the page changed in some way? Let's say your page is crawled by Google every 2 weeks. So it was crawled last week and you decide today you wish to 301 the page. You are suggesting to wait a week to let Google re-crawl the page before 301'ing it. My question is, what has changed on the page since the last crawl? What do you wish Google to see?

[tylerfraser]

Ryan,

No I'm not referring to a link.
There's nothing wrong with that statement and it was not taken out of context.
There's no additional information that I am concealing.

The 301 can go up immediately. The question is can the old url be deleted before it has been cached as a new url. After it gets cached it will show as the new url in the serps. Then it's safe to be taken down.

[RyanKent]

In a normal web page request, the requested page is provided by the host server with a 200 header code.

In a 301 situation, the new page is returned with a 301 header code. This would happen whether the old page is present or not. Even if the old page was present, the hosting web server would not look at nor offer the old page.

If there is no additional information or context, I would stand by my original statement. My question to the person who is the source of the statement would be, what exactly is Google supposed to see on the page before it is redirected? What has changed from the last time Google saw the page?

[tylerfraser]

interesting. the source was very reliable and actually I am agreeing with what you are saying. I'm thinking that google may (during this discussion in early 2010) go back to the actual old page in some way. Otherwise what would be the point of leaving it up? There may be a caviat in the googel algo that likes it when you seem transparent. This is the old page and this is the new page. Showing that you still have control over the old page. I understand that the googlebot wont even get to the page if it sees a redirect in the htaccess. So this is the reason for the question. I asked a private and question and we'll see what comes back.

[RyanKent]

I'm thinking that google may go back to the actual old page in some way.

To the best of my knowledge, that is simply not possible.

Google can choose to ignore the robots.txt. Google can choose to ignore a meta tag. Google can choose to do just about anything it wants with respect to page rankings and SERPs. What Google cannot do is access a page on a web server to which it does not have access.

Google cannot tell the web server "hey, I know you are showing a 301 here but I don't want to be redirected. Show me the original page instead". At least, they can't based on my understanding of how the web works. If I am mistaken, I would love to learn about it so I can improve.

[tylerfraser]

by http://www.seomoz.org/users/profile/22897

It depends a bit on how the redirect is implemented. People sometimes rush to remove an old page from links, XML sitemaps, etc. and then run into a bit of irony - if Google doesn't recrawl the old page, they don't see the redirect and may not process it (or they'll have to find the new page by themselves and kill the old page, which can take a lot longer).

If your redirect is at the server level, like an Apache htaccess directive, you may not need the old page to actually exist. The redirect will happen without it. Typically, though, I'd leave a reference to the old page, like a line in the XML sitemap, at least for a few weeks.

Of course, if the old page is frequently crawled (it has a lot of outside links, etc.), you may be just fine. It's typically deeper pages that dont' get crawled often that run into trouble.

I'm not quite sure what you're saying about changing nameservers (or how that ties to htaccess) though. What method are you using for the redirection?

by - http://www.seomoz.org/users/profile/22897

[RyanKent]

Hi Tyler.

Both the links you offer are to Dr Pete's profile page. I am presuming this response was shared with you for your private Q&A?

As a follow up to you or Dr Pete I would ask the following questions:

Would you agree the best method of redirect would be at the server level?

If so, would you agree that once a redirect is implemented at the server level there is no reason to keep the old page on the server, and that even if the old page was kept it would never be seen or crawled as long as the server redirect was in place?

If the answer to both of the above questions is yes, then it is in perfect alignment with the information I shared. If the answer is "no", then I would have further questions based on the response.

What method are you using for the redirection?

The first response I shared specifically clarified it was for a server (htaccess) redirect. I use that example since it is the most common form in my experience, but there are other ways to do it.

Thank you for sharing the reply. So far it sounds like it affirms the response I offered.