Config versus Code - what's the difference?

I have worked on a few projects lately where the the conversation typically went as follows:
"We aren't coding anything, we are simply changing the configuration within the product"
or "We don't need to deploy our changes to Subversion/CVS/BitBucket/GitHUb as it is config not actual code" (and sometimes the word "actual" is stressed).

Sound familiar?

So I thought I would define what I thought are the traits and differences between config and and code:

Config is:

1. Customisation of mature code, without affecting that code
2. Held in a source control system, wherever possible
3. Setting and changing parameters via simple instructions
4. Carried out using a visual tool or interface
5. Limited in scope (to what the developer wanted to expose)
6. Best suited to making changes to SaaS (Software-as-a-service) products

Code is:

1. Scripted or compiled
2. Always held in a source control system
3. Carried out using an IDE (Integrated Developer Environment) such as Visual Studio or Eclipse
4. Far less limiting in scope (to what the developer wants to do)
5. Where repeatable functionality is held
6. Best suited to the creation of bespoke applications

Or put another way:

If you need a developer to make a code deployment once a configuration change has been made (to implement that config).... it is not config!

Will One Line Of Code Help Your SEO?

There's been quite a lot of discussion online (and a little offline) about a recent blog article called: How I Sped Up My Site 68.35% With One Line of Code

I think the biggest buzz about this article has been in the SEO community, who suddenly got all excited about a magical way to speed up web pages. Mentioned by Moz (the organic optimisation industry's catnip) you could be fooled into thinking that one person had suddenly found a way to massively boost a site to the top of the results pages.
Note: For those who don't know, the speed a page downloads is cited as one of the numerous factors taken into consideration when search engines such as Google rank (judge) your site... having a much faster page load speed with just one little line of code would be fabulous.
But alas, that's not the case.

You see, I think this article is misleading as it explains how to use an HTML tag called "rel-prerender".

For those who don't know, the rel-prerender tag is used on a website to place into computer memory the next page the site developer expects the users to click on. For example, Google sometimes use it in their search engine results pages (SERPs) to make the experience of clicking on the first result much quicker.

To explain how this works on your own website, let's imagine you are on page 1 and want to automatically call-up page 2 behind the scenes (so that it appears very quickly). You therefore insert the "rel-prerender" tag in page 1 to call up page 2 before it is clicked on.

Where might you use this?
Well you might us it on a login-page (page 1) where the logged-in page (page 2) is usually the next step. You can even use it in an eCommerce site to pre-render the shopping cart I guess.... BTW: DO NOT DO THIS!

But as you would expect, there's a catch. Pre-rendering page 2 is the act of requesting a view of it in advance. So people arriving on page 1 can trigger a page 2 view without ever seeing it and in many cases they won't. This means that in some analytic packages this is recorded as a page impression (not in GA, it's clever like that) and ads on that page may be triggered even when nobody's there to see them. Plus it also adds load onto your servers whenever a page is requested, so don't tell your tech support person you're adding further load onto the system that may never be used.

So does it have an effect on SEO? Well I may be wrong.... but I really can't see how it helps organic site optimisation as you are not speeding up the render of the page you want to appear in the SERPs (Page 1). What you are actually doing is speeding up the potential delivery of the next page (page 2) you expect the user to see.  And that's not SEO, that's a caching strategy.

Further musings about Meta tags

In a recent posting, I mentioned how the Meta Keywords tag is no longer used by search engines to rank websites. Even Google now officially states that they don't bother with it... so as a search engine optimisation technique, I wouldn't spend any time on them.


This therefore raises the question of whether you should even include it in your site or if you should remove it.

So here's some thoughts on the pros and cons of keeping this tag in your site.

Remove them:

• Your site HTML code can easily be seen by viewing the source in your browser - PC's typically. This means the keywords always on display and can therefore give your competitors insight into the keywords you are targeting.
• Although a lot of people are now on super-fast home broadband and work connection, there are still a number of users on slower download speeds ... including those on mobile devices. Although removing a line of HTML code isn't going to make your site noticeably quicker, as one UK supermarket slogan goes... every little helps.

Keep them:

• HTML / Accessibility standards change and evolve from time to time. Therefore there is the chance that the Meta Keyword tag could be brought back into use (although very unlikely I guess).
• Some on-site search mechanisms might still use them to classify pages on your own web presence 
• If you're after throwing your competition off the scent of what keywords you're actually targeting, you could always put false ones in your meta tags... but then, that might be a little too much

The philosophy of content marketing

In a previous post I posed the Content Marketing equivalent of a long-standing philosophical question "if words are written and nobody reads them, are they really content?"

But the creation of content doesn't exist in a vacuum. To succeed at content marketing you don't just need great content... You also need:

100% code:
Just developing HTML that just about qualifies as 'fit for purpose' at the time of testing not only means that you may have issues down the line (e.g. when a specific browser is slightly updated) but may also hamper some of your SEO efforts. For example, some blogging platforms (e.g. WordPress) can take quite a lot of effort to get them SEO-friendly.

Killer UX:
Creating a fantastic user experience helps visitors browse your site with ease and complete tasks you want them to using functionality and content to inform them at every relevant step of the user journey.
So does content marketing include the use of  A/B and multivariate testing (MVT) approaches to optimise the user experience? You betcha! Alternative versions of content can have significant influence on visitor bounce rates and understanding... which can lead to improved conversion.

Exemplary 'white hat' SEO techniques
Forget the grey and murky areas of questionable search engine optimisation actions, your content marketing efforts have to be based on sound and utterly legitimate techniques. Why? Well thanks to the recent Google algorithm updates there is now an the even greater chance that less than honourable techniques could negatively affect your website's organic rankings.

Insight from digital analytics
A good analytical understanding of what your visitors are doing when they get to your website gives you the knowledge to evolve your content (text, imagery , video , animations, etc.) by changing it rapidly to respond to trends.

Advanced SEO : Using canonical references

What is Canonicalization?
The process of picking a single site URL to be indexed by the search engines from a range of URL’s. This happens when there are duplicate versions of the same/similar content on one site. Think of it as a way of suggesting the ‘true’ URL for your page(s) to the search engines

Why would I have multiple versions of the same content?
This usually occurs when you have dynamic content delivered from a database or there is more than one URL for a single page (typically the homepage, but not necessarily).
An example of this is an ecommerce site that enables users to get the same or very similar results from different actions.
E.g. If you have the URL of a product catalogue listing page built up from a series queries or filters.

The search engines understand this stuff?
Yes, they more than understand it they use it as a signal for search engine optimization. Since early 2009 Google, Yahoo and Microsoft have all stated they support this way for website owners to say “hey search engines, all these pages may have different URL’s but they are actually the same”.

What is the issue with duplicate content?
Search engines think that everyone is trying to game them and submit duplicate content to push themselves up the organic rankings. Without this, when a search engine finds duplicate content, it won’t now if you have done this accidentally or on. This means that they may well display the URL you don’t want to display, miss pages you want to get index or even worse downgrade the value of the page(s) they find… affecting the rankings and potentially the entire optimization of your site.

So how do I do this on my site?
If you read articles about this on the web, you would think that it is as simple as embedding a link in the header of your HTML pages (See: http://en.wikipedia.org/wiki/Canonical_meta_tag )

In theory this tells search engines the preferred location of the page to index (the “canonical” location) instead of the one it has found.

In practice it is more complex to create and maintain a working Canonical structure within an eCommerce site, especially one that has an evolving product catalogue.

Google looking to make AJAX crawlable

The problem a lot of sites have had over the last few years is that search engines are not able to crawl content delivered via AJAX (Asynchronous JavaScript and XML). This means that web crawlers doen't see what the visitor sees and a lot of Web2.0 content cannot be indexed - in effect discouraging those who want a site optimised for SEO purposes using rich interfaces.

But yesterday Google announced their proposal for a new standard for making AJAX crawlable.

These particularly technical recommendations hope to free up the content within AJAX-based sites, but need agrement from web server developers and search engines... a tall order indeed!

in reference to: Official Google Webmaster Central Blog (view on Google Sidewiki)