Changes in back end technology

[driller41]

I have just changed my site from .net to php - the backend needed to be changed - I had no choice.

I should have asked this before I started but are there any dos and donts, how should I manage the change?

[tedster]

The ideal would be to configure the server to parse .asp extensions through the php handler. That way you wouldn't need to change any urls.

If that's not in the cards for you, you should 301 redirect the legacy urls to the new version.

[driller41]

So would just recreating the pages as php pages with the content the same not be enough for the all knowing Google algorithm?

[tedster]

Remember that Google Search ranks pages. By changing the extension, you've changed the URLs for all your internal pages,. and all rankings that belong to your old urls are gone. You are also losing credit for any backlinks that point to your internal pages.

[mack]

Im with tedster on this one. If you have page.asp and name it page.php the url is totaly changed, so all ranking will be lost. A 301 redirect would address this and allow you to continue developing with .php extensions.

Setting the server to treat .asp pages as php would IMO be your best option, this means no page url's would change and the .asp extension would be handled like any .php page.

Assuming you are going to be on an Apache server the change could be set up using nothing more that your htaccess file at doc root...

AddType application/x-httpd-php asp

Mack.

[zaneta]

I had to move a site from IIS (Win) to Apache (UNIX).
It was .asp. I kept the same urls and parsed asp as php.
That's the way to do it, you just have to adjust the code.

In a newer perspective though, you can Rewrite the URLs and
route it wherever you want. I have used both methods and
this one is more efficient for coding.

[jd01]

What tedster said... and in an effort to donate back a little bit:

Assuming Mod_Mime is installed:

AddHandler application/x-httpd-php .net

Should do the trick...
With a little reference:
[httpd.apache.org...]

[dstiles]

You would imagine that a company that claims to be so clever could easily decide if a simple page extension change were just a tech thing or if the content had changed between the two files. I often doubt google's practical intelligence.

On the other hand, it adds to a webmaster's worries, and I suppose they think that can't be all bad. FUD.

[jd01]

You would imagine that a company that claims to be so clever could easily decide if a simple page extension change were just a tech thing or if the content had changed between the two files. I often doubt google's practical intelligence.

They're actually following Internet protocol and web standards, which I believe is a good thing, even if it gives you something else to worry about. The 'pages' (URI) are not the same and should not be treated as the same according to Internet protocol or web standards, and when someone places a link to example.com/some_dir/some_page.net that's where the link goes... Neither Google (nor any search engine) IMO should not arbitrarily attempt to find the 'new location' for the information and then count it as a link or the 'same page', because it's not and anyone who clicks on the link will receive a 404 error, unless there is a redirect in place, in which case, if done properly and through a single redirect to the correct location will be counted properly as a link and the 'new location' by G.

[pavlovapete]

driller41

are you 301ing the old URLs to the new ones? If not may I suggest you do this as a matter of priority.

And I second (or third) using the extension rewriting.

Cheers

[driller41]

Many thanks for the comments, the site is on a shared Windows server currently, I guess that limits my options somewhat.

Does the 301 have to be on each page or sitewide?

[pavlovapete]

Shared Windows server does limit you somewhat - particularly a mod_rewrite rule as mentioned in the posts above.

In your case I think you'll need to set up 301s for each page. I've used clunky 404 redirects on Windows servers in the past. Not real pretty or scalable to massive sites.