PHP request handler script and SEO

Question

Would using a central "page handler" affect SEO negatively?

eg A page request comes in for www.mysite.com/index.php, which mod_rewrite passes on as www.mysite.com/handler.php?page=index. Handler.php gathers the page-specific includes, language files and templates, and outputs the resultant html.

My understanding is that the page handler method won't be any different SEO-wise than serving index.php directly, as the content and publicly visible url remain the same regardless of the monkey-business going on behind-the-scenes, but I've been wrong before... :)

Answer 1

Search engines can only see the end HTML result. They have no idea if you're using a central page handler - how would they without hacking into your site's FTP?

Also, as many frameworks and CMSes use this technique - Drupal and WordPress come to mind immediately - Google et. al. would be lunatics to penalise it, even if they could detect it.

Answer 2

Because mod_rewrite happens within the server, the requester will only see that they requested index.php and got a response. Without a redirect, the requester will only know that index.php exists.

Many content management systems use this method. While in Drupal every page is actually served by the request /index.php?q=request/path through mod_rewrite, any links on the site will be seen as /requests/path, with the requester oblivious that they are all passed through one php script. There are modules as well that redirect the ?q= path to the 'clean path', telling the requester that the path with a query is invalid or doesn't exist.

Answer 3

A well formed URI is a bonus when it comes to SEO. It helps indexing. Consider that there are sites like PRWeb.com that sell you URI space. Not subdomains, but URI keywords.

Also, while many customers merely want to mouse around, astute web users are impressed with an intuitive URI pattern. If you chop the filename off a path, you should get something logical, like a homepage or an index page, not an error screen.

If your application will eventually be statically cached, you want to able to leverage the file system. So if you have content that will publish well in a static form, I wouldn't hide it behind a convoluted query string.

Also, when conducting web analytics, having an easily parse URI certainly helps you craft your reports.

Your URI doesn't have to correspond to your filesystem. REST style APIs make it quite common to use pathings as a way to divide up areas of their APIs. Your application might leverage some pathing in the URI as a way to separate features. For access control, too: if you want to restrict Googlebot forinstance, it doesn't make a lot of sense to put ?action=blah in a robots.txt file. It does expect paths and fileglobs.

Apache mod_rewrite is awesome. I love it, I live it. I'd rather design in mod_rewrite to proxy a consistent URI space to a changing application codebase early, rather than use mod_rewrite as a bandage on an aging file structure or application layout.