WordPress & CMS Design Decisions For Multinational Search

We've seen a number of queries on the suitability of various platforms for SEO, and so I've pulled together some pointers that may prove useful when choosing a commonly available, free, website platform for a site that will - either immediately or at a later date - be expected to deliver an SEO friendly website that can dominate the rankings in multiple countries.

Chat with SearchBot

We’ve seen a number of queries on the suitability of various platforms for SEO, so I’ve pulled together some pointers that may prove useful when choosing a commonly available, free, website platform for a site that will — either immediately or at a later date — be expected to deliver an SEO-friendly website that can dominate the rankings in multiple countries.

WordPress: The World’s Favourite CMS

Wordpress Logo Stacked BgWordPress is clearly the most talked about — and most commonly deployed — CMS in history.

However, WordPress suffers from a lack of credibility as a truly first-class CMS for multiple users in a business environment; although its ease of extensibility means there are no shortage of modules to morph what was once a simple blogging platform into a fully featured corporate CMS.

Numerous plugins, such as Yoast’s excellent module, can resolve most of the indexing and on-page SEO issues that plague sites created without a thought for the search engines. This allows you to focus on more complex areas of optimisation, like video and social integration with the search result pages (for example using a video sitemap XML allows you to be seen as a “Provider” to Google Video search and therefore eligible for inclusion in Video snippets brought into the main Search Engine Result Pages), and SERP conversion techniques such as including strong sales “call to actions” (i.e: triggers encouraging searchers to click) in your SERP snippets.

Auto tagging for category terms, along with a rigorous, and limited, category set allows for nice targeting of mid and top level search terms automatically as relevant content is tagged up.

But all of these extensions will be worthless if we can’t effectively implement them for multinational installs of WordPress itself, so let’s dig a little deeper in the practicalities of that.

The Suitability Of WordPress For Multinational SEO

WordPress’ ubiquity could be its biggest strength, particularly if you anticipate local territory webmasters needing direct access to control their own content. A huge amount of training literature and video content already out there for WordPress can be easily tailored into a short guide you can deliver to each region webmaster.

Given the depth of WordPress’ penetration, you’ll also be able to deliver the training literature in the local language, and using extensions that build on the underlying multilingual codex such as Bogo delivers the ability to show different language admin areas for different users.

However, it is not an optimal solution to have to install multiple instances of WordPress to enable the multilingual functionality as advocated in the official WordPress multilingual guide.

A developer’s ideal solution would involve a single install of the code required to execute content delivery to HTML pages from your database, with only language files requiring installation to expand the functionality to other languages.

This is something that is handled quite elegantly by the 0bject-oriented Python framework Django.

There is also an issue that is related to the multiple install problem, which is caused by WordPress being language-centric, rather than country centric.

Localising To Countries, Not Languages

To optimally deliver SEO in different countries, each country section of a site should be localised in Google Webmaster Tools to a country — not to a language.

This is why I advocate a single domain architecture of either subdomains for countries (ideal for other technical reasons covered in an earlier post of mine on Search Engine Land), or root directories for countries, with subdirectories for languages within the country.

So: ca.example.com/en/ or example.com/ca/en/ when building an architecture for English language content intended to be localised to Canada.

Currently, no off-the-shelf solutions exist for WordPress that are able to support this country/language combination as a root for multinational content. Of course, I’m happy to be disabused of this and my ignorance shown up in the comments section!

Controlling User Permissions

Fine-grained user permission controls are essential for a multinational CMS, particularly with content being edited by local webmasters spread across multiple offices who may not all have the same level of technical proficiencies, or be aware of critical pages for other locations.

Protecting well-performing pages from accidental changes to their URL — or in the worst case deletion (or at least archiving) — is a basic requirement, and forcing content that’s published by particular users to fit with the URL hierarchy just discussed is also a fundamental requirement.

Tracking down where Spanish content went that was written for the North American section but that was accidentally published to Spain is not only quickly going to try the patience of your webmasters, but also cause inefficiencies and entropy toward misposted content that doesn’t deliver a relevant call to action for the country.

Extending permissions to allow local webmasters to commission freelance content production directly to the site will likely be necessary, and again, should also allow lock-in on the correct local territory “soft root” of such content.

Again, this sort of control is handled quite well by Django’s admin system out of the box, as permission controls can be as fine grained as required, and very easily extended. A multi-site Django deployment can also be used to deliver content to multiple subdomains, each of which can have optional language variations added from their admin language repository.

Security & Support Concerns

It’s pretty obvious at this point that my preferred solution wouldn’t be an off-the-shelf WordPress install, and instead a slightly customised version of Django.

That’s partly because it handles the URL architecture and publishing controls very elegantly, but also because of the final — and most important — point to consider for our multinational website: security.

The reason we are blessed with a multitude of SEO plugins that make administrating our website content for SEO easier is also a problem: popularity.

Just as Windows machines are constantly attacked by spyware and malware authors because they have the largest marketshare, so WordPress is plagued by frequent required updates to solve security breaches.

We don’t want to incur overhead in managing our CMS by requiring an upgrade every month. Especially not if we have developed our own custom modules to try to deliver a URL and permissions architecture that’s fit for multinational SEO purpose.

So, one of the simplest solutions for improved security is to look at a different platform.

Django, we’ve discussed already. But for PHP alternatives, Drupal and Joomla, in particular, have much to recommend themselves, as they have been designed for more commercialised sites in the first instance, and their underlying PHP lends itself to multi-site deployments with multilingual sections that can also transition into eCommerce platforms easily — another area where WordPress support is less than comprehensive.


Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.


About the author

Chris Liversidge
Contributor
Chris Liversidge has over twelve years web development experience & is the founder of QueryClick Search Marketing, a UK agency specialising in SEO, PPC and Conversion Rate Optimisation strategies that deliver industry-leading ROI.

Get the must-read newsletter for search marketers.