BRIXS is a new employment agency which specializes in recruiting, payroll, and career guidance for job seekers, college graduates, employers, the self-employed, and professional athletes. Through daily contact with specialists and relevant companies and organizations, BRIXS know exactly what is happening in the workplace and which candidates and positions are available or becoming available.
As part of their marketing strategy, BRIXS wants to profile and promote their business through their website. Yet a quick glance at search results showed that their previous website was nowhere to be found and that the competitive and mature industry offers little space for start-ups to gain a decent SERP let alone to rise fast in page rankings.
Drupal was chosen primarily because of its flexibility, security, modularity, stability and the rich availability of all kinds of contributed modules.
The secondary reason is its architecture and structure; specifically Drupal's logical processing of functions and hooks which is key to its flexibility and provides developers with the opportunity to customize output in numerous ways.
Additionally, its worth mentioning the hierarchical taxonomy system which allows content to be categorized or tagged with keywords for ease of access.
To find and implement methods through which a new job posting website could achieve competitive SERPs against industry giants like Monsterboard and Indeed, thus becoming visible to a bigger audience and realizing an increased CTR (Click-Through Ratio).
Pre-project analysis showed that the leading companies in this field gained their lofty positions mainly by being longer established than their competitors. Other important factors for their ongoing success include marketing budgets, and the size of their business networks and high-profile corporate connections; all of which a small start-up business would struggle to compete with.
Luckily for BRIXS the analysis also showed that cutting edge technologies implemented by the same industry leaders is not what you would expect given their massive budgets. Thus an opportunity presented itself:
Realization of a semantically-enhanced and 99.9% perfect website (the internet is dynamic, so a 100% score will forever be impossible).
Of course usability and backward compatibility are equally important factors to take into account but that is a case study in itself and won't be covered here. Instead, we will focus solely on technical SEO and server performance.
- W3C standards
- Google PageSpeed rules
- Yahoo YSlow rules
Server side compression
To measure the effects of technical SEO implementations the following test tools were used
Analysis of alternatives
New vs. current Doctypes
HTML5 is fast becoming the markup of choice and comes with the added kudos of perhaps stealing a technical lead over competitors with long established websites based on older core technologies. HTML5 offers many new semantic elements which may provide some hidden enhancements but at the time of writing Browser and search engine support is still quite incomplete and inconsistent.
We took a pragmatic approach and chose to stick with XHTML using the XHTML+RDFa DOCTYPE. But further than that, we implemented the semantics made available by Schema.org
RDFa vs Schema.org
From an SEO point of view there now is practically only one choice for coding websites with structured data, namely Schema.org. Although RDFa came first, is native to Drupal and provides more extensive vocabularies Schema.org is the only structured data set that is supported by all major search engines (Google, Yahoo, Yandex and Bing) while others (Baidu, Ask) are showing interest.
To bluntly put it, RDFa will never have that kind of support and in the cruel world of SEO and commerce this is what counts.
Having made the choice to go with Schema.org the following problems arose
- Schema.org isn’t part of Drupal (yet?)
- Existing modules don’t cover the full extent of what Schema.org can provide
So how did we go about implementing Schema.org?
In short, just about every tpl.php was customized and we implemented an insane amount of theme hooks!
A call to all
The developers are seriously interested in contributing to modules that help implement schema.org in Drupal while maintaining the freedom to work outside the box. Therefore any and all are hereby invited to study the HTML source of the BRIXS Group website and to contact the developers to open discussions and chew over ideas on how we as a community could develop modules in such as way as to handle the breadth of structuring possibilities that Schema.org can provide.
LAMP vs. WIMP
Drupal is open source, so is Linux, Microsoft isn’t. Enough said.
Varnish vs. stacked cache providers
Varnish is an amazing tool, but turned out to be a lot slower than the current stack of cache providers configured on the server:
- Drupal cache
- mod_pagespeed cache extend
All of the above modules are configured for performance and to cooperate with each other as required.
During development the server was configured with Varnish as a reverse proxy, but measurements showed an increase in download- and response-time. These increases could add up to 35ms per request.
Nginx vs. Apache
Nginx can be fast but creates a lot of configuration issues and errors that can’t be overcome when used in combination with mod_pagespeed and other server candy. Configured as a reversed proxy on the same server it created many problems with the server’s stack of cache providers. Many mod_pagespeeds modules stopped working and the server became slower because both servers needed to be running next to each other on the same VPS, which has only a single processor and a maximum of 3GB ram available.
The decision for not using Nginx can be reconsidered when scaling to multiple servers with a reverse proxy over multiple VPS's. But for our use case, definitely not worth it.
What's been left out
Due to the available hosting budget, the website is served using one local VPS. The final step in serving a fast-as-lightning website should be the incorporation of a Content Delivery Network (CDN). This was beyond the scope of the original project but will certainly be considered when the expected increase in website traffic boosts revenue. Until then, it's just not feasible.
For now BRIXS is focused on the Dutch employment market and therefore the website is hosted in the Netherlands. This effectively guarantees fast response and download times when you visit the site from any location from within Holland; although statistics from international visitors are also impressive.
So that's the first phase of the project complete. For the second phase we have a wish list of a half-dozen or so new custom modules. When funding becomes available for development and marketing (driven by the previously mentioned increase in traffic) we will have a better idea of what more can be done.
The potential for a responsive design and a mobile version of the website also are on our wish list. But so far as SEO is concerned there are pros and cons that must be considered and evaluated.
On the other hand, a 'true' mobile website could reduce download size by delivering to the device only the most important and relevant information.
Aside from these technical SEO considerations, there are other factors too. Some of us think a responsive design may not be needed because soon just about every mobile device that is coming onto the market has a Retina or HD display. This might suggest resolution won't be an issue in the near future. But that's a side note because it's a personal opinion and we know enough developers who disagree with this, even within our own development team. Needless to say, internal discussions are ongoing.
After achieving extreme low website/server response times and near technical perfection Google indexed 8500 pages within the first week and started showing rich snippets within 48 hours of website launch. This resulted in an 800% rise in unique visitors and a 1100% rise in page views within the first two weeks. Within six weeks visitors were up by 1200% and pageviews by 1300%.
Who dares to guess where this will end?
Special thanks go out to Tezza for all his input and taking the content of the case study to the next level. =)