Matt Cutts Wants Simplified Apache Configuration (Including Mod_Rewrite)

Apache Configuration is Too Complex (including Mod_Rewrite) – Matt Cutts Wants Simplification…

In this recent blog, Matt Cutts is encouraging developers to create solutions that will simplify Apache web server configurations for webmasters. He notes that while Apache is the world’s leading web server, it can be tricky to configure and set-up redirects, mod_rewrite, and .htaccess, etc.

Google and Matt Would Like vBSEO’s CRRs!

Originally Posted by Matt Cutts

A few of us were talking about this at Google. … Maybe a tool to take a list of desired redirects or rewrites, then output the correct syntax that you could cut and paste into a web server config file?

vBSEO’s Custom Rewrite Rules (CRR) takes this a step further.

• We recognize that the average forum admin is not going to be an expert at manipulating the intricacies of mod_rewrite, .htaccess, or http.conf – that’s for certain.
• While vBSEO fully converts vBulletin into a 1-URL-Per-Resource SEO powerhouse, the number of vBulletin custom hacks that are available now (and will be in the future) make a system to extend our users ability to convert all of their URLs to static an absolute necessity.
• Thus, we created CRRs to address that need. And, it seems that we’re one step ahead of the gang at Google in this context:
  
  We do not require the cut-and-paste! Unless of course, you’re sharing a CRR contribution provided by our members in the Custom Rewrite Rules forum.

Notes on vBSEO

• CRR stands for “Custom Rewrite Rule”. vBSEO’s admin control panel (vbseocp.php) allows users to specify simplified regular expression codes that will convert other common vBulletin hacks from dynamic to static URLs.
  
  With some tweaking, anything that is plugged into your vBulletin forum can be rewritten... But the real power in CRR rewriting is not just changing a .php for it's equivalent, but unifying multiple (complex) URLs into leading to the same content... into a single URL!

Let’s take vBA Links Directory as an example. The default URLs allow access to the same record via 6 different URLs:

Code:

/links/showlink.php?do=showdetails&l=ABC
/links/showlink.php?do=showdetails&l=ABC&catid=newlinks
/links/showlink.php?do=showdetails&l=ABC&catid=poplinks&orderby=views
/links/showlink.php?do=showdetails&l=ABC&catid=poplinks&orderby=rating
/links/showlink.php?do=showdetails&l=ABC&catid=poplinks&orderby=posts
/links/showlink.php?do=showdetails&l=ABC&catid=searchresults&searchid=1

A SINGLE CRR rule will create ONE URL for all of the above URL variations, replacing them wherever they occur on your forum with:

Code:

/links/link-ABC.html

This brings you even closer to 1-URL-Per-Resource link consensus.

Does Google prefer static URLs to dynamics?

Although Google itself says statics are preferred, some people still debate the necessity.

However, this is no doubt that providing a single, unified URL for each unique page on your forum is the absolute best scenario for SEO purposes!

For Discussion

• Prior to vBSEO, the complexity of configuring .htaccess, mod_rewrite, etc. made free mod_rewrite based hacks prone to error – and too difficult to support for non-dedicated teams.
• As the vBSEO community grows larger everyday, should vB hack developers now seek to format their dynamic URLs in a way that facilitates more advanced CRRs?

Source:
Matt Cutts: Gadgets, Google, and SEO » Simplifying Apache configuration?

vBSEO's Custom Rewrite Rule Interface:

I couldnt agree more with what you mentioned regarding the simplification of defining mod_rewrite rules. The CRR system is ingenious, and hopefully patended! I'm sure Matt would be interested in what you have produced and you could apparantly earn upto $4500 because of it

You are writing some great articles Joe. Very impressive.

One point is needed to be mentioned regards crr's:

There are some very poorly written vBulletin plugins out there, poorly written in terms of having the multiple url's per page. While the crr that you mention is a great solution, it also stops some of the functionality of the packages. Photopost and vba links directory both require the category to be in the url so that they can show the next photos/links by category. They ought to be using cookies for this, rather than putting the variables into the url.

I have just had a fresh look at photopost and confirmed this

HTML Code:

http://www.photopost.com/photopost/showphoto.php/photo/6456/cat/500/ppuser/179069
http://www.photopost.com/photopost/showphoto.php/photo/6456/cat/500/limit/recent

The packages also don't have good onpage optimization either - wording in the right places, or sitemaps. But that is another story!

Good point. We can take a very simple look at application development as a 3 layer model: (1) data, (2) business logic, and (3) presentation.

At first glance you might think that (for web applications) we can simply add an extra layer for "SEO". However, it's now becoming quite apparent that SEO is a sub-layer that must be addressed at each of the other 3.

SEO should influence how data is created/stored, manipulated, and displayed.

Now we just have the *easy* task left of convincing vBulletin developers to start developing with SEO in mind.

Fortunately, our CRRs are helping to made improved SEO a reality for vB admins making use of 3rd party hacks.

Originally Posted by Joe Ward

Good point. We can take a very simple look at application development as a 3 layer model: (1) data, (2) business logic, and (3) presentation.

At first glance you might think that (for web applications) we can simply add an extra layer for "SEO". However, it's now becoming quite apparent that SEO is a sub-layer that must be addressed at each of the other 3.

SEO should influence how data is created/stored, manipulated, and displayed.

Now we just have the *easy* task left of convincing vBulletin developers to start developing with SEO in mind.

Fortunately, our CRRs are helping to made improved SEO a reality for vB admins making use of 3rd party hacks.

Hopefully now, more third party plugins will take more care and time on more than just the coding aspect of the plugin but also its aesthetic and usability functionality not only to the user but to search engines too. Especially commercial modifications such as vBadvanced portfolio of products.