It’s been, like, forever, since my last post in this series – feels like time to pick it up again and finish the series…
The suggestions in this post are focused on the “behind-the-scenes” elements of your site – to the untrained eye they may not be visible/obvious.
This post definitely sways towards the geek end of the spectrum (just a fair warning if that’s not your thing). However, even if you’re in management, it helps to understand these things for when you’re briefing your tech team.
Web standards and the “semantic” web
The web is built from a range of technologies, many of which are based on standards managed by the World Wide Web Consortium (or W3C for short) – things like HTML, CSS and JavaScript.
These standards define how a web page looks and functions. In recent years there has been a strong move towards “standards-based” web development because of the many benefits this provides.
These best practices focus on using specific HTML elements for their intended purpose – for example, making sure you use the HTML “heading” elements (<h1>, <h2> etc.) to represent the various headings on a page – and using other technologies (such as CSS and “unobtrusive” JavaScript) to represent the design and functionality – e.g. the font size, colour and positioning; or custom functionality such as drop-down menus – independently of the underlying HTML.
Often this is referred to as “semantic markup” or the “semantic web” (the concept of the semantic web is broader than presented here, but semantic markup is an essential element).
While I can’t go into the many details of semantic markup, using such markup is very important for search engines. This is because many search engines will use the HTML as cues to what information is important in a document – e.g. the text in a heading may be considered more important by the search engine because the page author has signified, through the use of specific HTML, that that text is more important (i.e. we are embedding “meaning” and intent into our content by using certain HTML elements).
Accessibility
Good accessibility practices also help here. For example, images with no “alternate” text are problematic in all number of ways, but for the purposes of this article it’s suffice to note that they are also invisible to search engines. Sites made purely from Flash, or including Flash elements without appropriate alternate content, may also not be indexed by search engines (yes, Adobe have worked to make Flash more visible to search engines and accessibility devices, but it’s still important to provide alternate content).
Another case of “best practices” benefiting both your participants and search engines (do I sound like a cracked record yet?).
Other considerations
The amount of unnecessary HTML you have in a document can even be an issue – I’ve read/heard that some search engines may not process all of your page if there’s too much markup as they want to keep their search crawlers efficient. And the order that content appears: search crawlers may treat content higher up the page as more important.
Tech-team skills
A good web development team/agency will naturally create HTML/CSS that is semantically rich and well structured. Unfortunately my experience is that many agencies and companies pay lip service to web standards, only to deliver finished products that are far from exemplar.
It’s important that you ensure that your team is across these concepts and has the practical skills to produce good code. This may require training (for in-house developers) or asking some hard questions and getting technical advice from a trusted third party with the necessary skills when choosing your vendor and evaluating the products they are delivering.
Content Management Systems
Nowadays most websites employ some form of Content Management System (or CMS), whether that be a blog engine like WordPress or a more feature rich (read: more complex) system such as Drupal or Joomla.
Some of the recommendations made in this series may not be possible without modification or extension (e.g. through plugins) within these systems. I believe that these factors should be included in your consideration CMSs for your organisation.
Content entry
In my experience it is common for non-technical users to content into a CMS. This makes a lot of sense for a whole bunch of reasons, ranging from a desire to ensure that content is kept up-to-date by distributing the editorial responsibility to resource constraints where in-house development/technical expertise is limited.
This has a significant impact on whether or not your content is SEO-friendly (i.e. using semantic markup). If the CMS has a WYSIWYG editor for entering content – e.g. you enter content into a field with a Word-like toolbar – quite often the HTML that is generated by the editor is not as clean and semantic as it could be (sometimes it can be down-right problematic).
It is important that any CMS choice takes this into consideration and that the person(s) entering content are correctly trained to use the system in a way that generates appropriate HTML. This may include some training in the basics of HTML so that they can get “under the hood” and tweak the HTML accordingly. Alternatively, your business workflow for content may include a step for a technically-oriented person to “clean up” the content after it’s been edited by non-technical users.
While I know how frustrating it might be for subject matter experts to learn basic HTML, or for someone to have to clean up content after the fact, this step is quite important to undertake such a step to ensure your site is performing as well as it can.
To be continued…
And that’s not all – in the next installment I’ll cover off some more of these “invisible”/more technical aspects of a site that should be considered.