OK, now it’s time to apply a graphical header across both Blogger and the main site. And it’s time to make some commitments to a CMS system for the main site. There are many CMS systems out there, and the last thing I’m going to do is go through the learning curve on even an easy one. Is a website a Web application or a bunch of HTML files? For manageability, it has to be thought of as a Web app, but for search optimization, it needs to be thought of as HTML files.
Blogging software has long ago solved this by “outputting” static HTML files from their database. This has a plethora of advantages, including reducing server load (serving static HTML files is much easier than executing code). Even if your dynamic pages are masquerading as static HTML, you’ve got increased server load—now two-fold: first, from the invisible reformatting of the URL that takes place with the Mod_Rewrite technique, and second by executing code that probably queries a database, populates variables, then finally serves up the page. Static pages, while providing less customizability, are much better for high volume sites.
I believe I’ll be using our own home-grown CMS system for the rest of the MyLongTail site. The back-end controls don’t have the features or the polish of other CMS systems, but I know it inside and out. It gives 100% uncompromising artistic control (unlike most CMS), and it creates pages that are perfectly optimized static HTML for search engines. And best of all, when things change on the Internet, I can just re-work the XSL transformations, and appease the search engine algorithms du jour, at least as far as internal link structure is concerned. Our home-grown CMS system was designed specifically with SEO in mind, and more particularly, with non-commitment to website architecture or technology decisions. Very advanced XSL queries “knit” the website together, very much the way blogging software can rebuild the static pages of a blog. But because we control that transformation.
Anyway, I need to go through the steps I would take for any website using our CMS for SEO system. I will need at least one page on the site. From a scalability standpoint, my home grown system is great when the entire site is going to be HTML. But much of this site is going to be an application. So, while I’m starting it this way for expediency’s sake, I very well may switch over to Ruby on Rails for an SEO-friendly app site. Additionally, much of the application will be written with AJAX, which is inherently SEO-unfriendly.
So as the site becomes more application-like and cooler and cooler, it will simultaneously be becoming less friendly to search engines. That’s part of the reason why the blog is so important (Blogger is inherently SEO-friendly). Blogging lets us roll out content in a friction-free environment. Anyone who has managed corporate websites knows what I mean when I say friction. Because I’m blogging from Microsoft Word, I can roll out content with almost no friction. But the content that becomes the navigational framework of the site will be from my home-grown CMS, which is also inherently search engine friendly. Together, the blog and the navigation pages will create a very competent placeholder, so it can start setting properly into the engines.