Greetings-

I am a wh

SEO

 /webmaster by day in Chicago and I have a professional dilemma. I've inherited a site which has approx. 500 .html pages. So I've been thinking that I could use .

php

   to better manage the content. My problem is that I'm unsure of the best way to go about this e.g .

php

  tables or changing the .html pages to.

php

  with a .htaccess mod-rewrite, etc. I'd greatly appreciate any insight that the members of the forum could offer. Thank you very much in advance.

GG

If I were in your shoes I'd probably use a mod_rewrite to change the .html to .

php

 , then of course change all the files from .

php

  to .html so they are grabbed and process correctly.

First concern: Don't mess with any ranking/pages that the engines already have - let them assume that nothing has changed.

/p

The existing rankings are very important to me. Another concern is how to go about parsing the .html and making the changes to .

php

   in a wholesale fashion?

GG

(dum dum dum). the mod rewrite handles the change of extension.

Right - mod_rewrite will handle the redirection of /afile.html to /afile.

php

 .

As go the files, you can use rename if it's

linux

  like this:

rename sourcepattern destpattern sourcemask

so it'd look like this:
rename .html .

php

  *.html

You'll have to do that for each directory, but it'll get all the files for you.

Good luck!
/p

Perk...how do I make certain that my rankings remain intact if I go the .html to .

php

  conversion route?

GG

Ahhh... you're confused on the workings of mod_rewrite.

Mod_rewrite can be used to tell a surfer or engine that a page is at a new location... which sounds to me what you are thinking. It can also be used to modify what page is pulled up from a server without the surfer having any idea that there was a change. So for example, a surfer pulls /adir/apage.html but your server rewrites it to /anotherdir/anotherpage.

php

  - so although the surfer asked for the original URL, what your server serves up is the second URL. The surfer does not detect the change ... because there hasn't been any according to the outside world. Then change was completely internal to your server.

This mode of URL rewriting is extraordinarily common and is not, in any way a BH technique - it is a straight ahead technique for managing web servers. One of the earlies examples I'd ever seen was a guy that rewrote inbound URLs to grab pages from a user's directory on the server.

I'm going to look to Bompa/Dirk/others to correct me here because I have not done this specific rewrite (I do a lot, just not this type) and I'd strongly advise that you use logging to see how the rewriter is doing because it's complicated at first. In this example I've set it to a level 10, which is completely verbose - but you'll want to shut that down in production because that log will get massive in a heartbeat. Here's my first shot at it:



I've tried to avoid anything with parameters here, because this will be a problem for you.

I thought about another way to do this that I'd actually do: rewrite *all* requests into a single .

PHP

  file, then grab and return the original HTML file. This has the added benefit of allowing you a "tracking point" instantly because everything comes through a single

PHP

  script. First step, rewrite everything into a script, second, the script itself:



Now, everything that comes to the website will be changed (internally remember, not externally) to a call to main.

php

  with a single $_GET parameter of ['url'] which will contain the original file name. So at the most most most basic in

PHP

  you'd have:



... but of course, since you are in a single point script for the entire website now, you can do *anything you want*.

This is exactly how all of my websites work. It gives me central control on tracking, GEO targeting, if I require a little something special for certain surfing entities hitting my sites and the ability to dramatically change the website with a few changes to a single file. I can go on here, but I'll bet you get the idea.

Hope that helps!
/p

May I suggest simply adding a .htaccess file (or editing httpd.conf if you have root access) and adding the following line.



That will mean that all your URLs will remain the same and you can start to code with

PHP

  inside the existing files with no discernable difference to the search engine or visitor. It will make your life easier though as you can start to adapt your infrastructure immediately with no worry about URL changes of any kind.

I would suggest that once you have decided on the right strategy for your site, no matter what it may be, that you then 301 old URLs to new URLs but at least this way you can start right away with some 1st stage functional changes for the individual pages themselves.

I did very similar to this years ago (many eons actually) when "management" at a major "international news" newspaper, tv and web business told me that we should be using JSP pages as he had heard they were the "right way" to run a website.

"What a wanker I thought" but he was the boss so jsp is what he got!

Code below from memory - But close enough to understand

Hey JD -

Forgot about the app-type - that's a nice solve as well.

Since he's gong to a 100%

PHP

  solution @ this virtual host, there'd be no issue with that at all. Simple, duh. 

Yes
what the duke said

Perk your a legend, more patience than a saint