Still making the same SEO mistakes?

I'm amazed that so many existing & newly
-developed websites are still making so many Search Engine Optimisation mistakes. It seems to me that so many organisations are ignoring the basics when it comes to organic improvement of their main online asset.

I see it time and time again:
- Poor keyword analysis
- Unrealistic placement targets
- Poor quality coding
- Duplicate (or very similar) content
- No redirects for deleted pages
- Badly written content

Why is this?

Site launch checklist

I was recently asked for a checklist of essential items to check on a website before it launched. So I have shared it with you all here:

Page titles
You should know by now that every page must have a page title. It's what appears in the top of the browser for that page and how it gets shown by default as a bookmark or Social Media post.
However it is also a key Search Engine Optimisation ranking factor, so ensure that it is relevant, the right length (approx 55 characters including spaces seems to be fine) and ideally unique across your new site. There is also a significant consensus in the SEO community that the keyword you are targeting for this page should be as close to the beginning of this title as possible.... but I will leave that for you to assess the value of.
Also since Google usually displays just the first 50–60 characters of a title tag, I would keep to that range without very good reason.

Meta data / Meta tags
These have grown in the number and function they perform over time, with some having a bearing on Social channels and SEO. But the key one here is Meta Description.
I'm not going to give you advice about what to exactly write in this field... as I've covered it in so many other blog posts. However, ensure that have a description on every page (correctly placed inside the <head> of the page). Plus consider that the current average length of the description field for desktop results is around 160 characters, whereas an average of 130 characters for mobile seems to be the best.
Note: Ignore using Meta Keyword tags

Sitemap
This little text file (mostly named sitemap.xml) usually sits in the root directory (or obvious sub-directory) of your site. It is a tried & tested way to tell search engines which pages are available for them to be crawled. It does this by giving a list of URLs for every public page in the site along with extra metadata about them.

Robots.txt
This little text file (all lower-case only please) should sit in your root directory of your site. It is usually the first file a search engine bot checks on a site and is there to tell all or individual bots what they are NOT supposed to do. For example, they are supposed to ignore certain directories or files.
So in this way it is the opposite of a sitemap.xml file and care should be taken to not have pages in both.
Note: some search engines may ignore the robots.txt so do not use this as a way to  hide site content or data you definitely don't want found.

Redirects
When launching a new site, URLs can change.
At the most fundamental level, this can mean a change of domain (e.g. brandx.com to brand y.com) or a change of sub-domain (e.g. blog.brand.com to brand.com/blog). So sites should ensure they understand and handle all redirects correctly at new site launch.

Minimum Viable Experimentation

Those who work in the digital and agile world should be pretty familiar by now with the implementation of a Minimum Viable Product (MVP). This is the creation of a working product that doesn’t have to meet all requirements, but allows further testing, feedback & iterative improvements. It is an approach pretty well understood and used across the industry and one that should lead to better products sooner.

So perhaps we need to use this approach, not just in the creation of the initial product, but in the way we release further functionality & features to our products? This would mean focusing less on the usefulness what each new piece of functionality provides (in economic terms the 'utility'), but basing each successive development on what it tells us about the product's overall ability to meet the wider strategic objective?

In other words, rather than add new stuff that simply compliments the overall richness of the experience... shouldn't each new tangible delivery be based upon a hypothesis? And in-turn, shouldn't this hypothesis be derived from insight that is focused on improving the user's needs or outcomes?

For example... if your project aim (which I assume directly linked to your strategic objective) is "to have a better online sign-up process for a new credit card", then each successive sprint or release from the initial product launch should be delivered to address this aim. However you shouldn't just assume that this is the case. 

Firstly make sure that each time you plan your deliverables you are actually answering a question, such as:

"How can we stop [a specific type of customer] exiting the online form before the end of the process?"

Secondly develop a hypothesis that can be tested in a small experiment. Such as:

"We believe that by adding [1: a specific feature] at [2: a specific point] we will create [3: an expected behaviour] by the user and therefore they will reach [4: an outcome] that will improve [5: a goal]."

Where in our new credit card sign-up example this could be:

1	A specific feature	A reassuring statement about financial approval
2	A specific point	The 4th of 5 pages in the process, where the most users drop out
3	An expected behaviour	The user is reassured that they could be approved easily
4	An outcome	The user moves to the 5th (and final) page of the process
5	A goal	Form conversion improves

It is worth stressing the point that these experiments don't have to be huge or complex, and in some cases making changes to a piece of content or image may be sufficient. They just have to be enough to prove or disprove your experiment's hypotheses…. a minimum viable experiment and nothing more.

What question are you really trying to answer?

Agile

Digital Transformation
Self-service technology
Faster delivery
<yawn>

Heard it all before? Yes, so have I... numerous times and across many different clients.
Each is craving to "move to become a digital organisation" or "reinvent their online proposition to embrace change" and other similar modern and (to be honest) pretty meaningless statements about themselves.

But I think they are approaching this the wrong way. 

On the basis that each company exists to provide a product or service to another (person or company)... why the heck are they not focusing on asking more questions about what their customers need? Or questioning what stops their valuable users buying/using/engaging more? And more fundamentally... why aren't more people tasked with trying to answer those questions with the creation of better products and services, increasingly delivered as software?

So rather than saying "we need to redevelop our website to improve our KPIs"...
You need to ask "why don't we make it easier for customers to convert?"

And rather than stating "we need to reduce the number of clicks in our online booking process".
You need to ask yourself "why do customers seem to have a problem getting past the 4th page?"

It is only then that you get to the creation of an insight-based hypothesis to change a process or product. 

Is data driven marketing that simple

In a Linkedin.com post recently I commented about the increased adoption of data driven marketing ...

It's simple really:
1. Build insight with real data
2. Foster loyalty
3. Communicate creatively
4. Analyse to improve

But is it that simple?

How HCI and API design are similar

All software needs an interface. Having one makes it possible to use the functionality and consume the data that lives within that software.

Humans use interfaces for software all the time, with the World Wide Web arguably being the biggest interface there is (OK, perhaps some websites aren't the best examples of usefulness in this mass experiment).  But put basically... they allow human-to-system interaction, also known as Human Computer Interaction or HCI for short.

Human Computer Interfaces have the following principles:

1. They remove complexity:
   By making it clear what each function does (e.g. do not have two ways of doing similar things)
2. They follow standards:
   By following established conventions (hyperlinks, buttons, tick boxes, etc.) they provide consistency.
3. They make interaction easier:
   By enabling swift and efficient relationship with the underlying data & processes and providing feedback or a response when something happens.

And Application Programming Interfaces (APIs) play a very similar role, but in a slightly different system-to-system manner. They:

1. Remove complexity, by (hopefully) providing a single request & response for each individual function
2. Follow standards, usually in the form of an API specification, to allow consistent development against them
3. Make interaction with the underlying systems easier via a standard set of methods (GET, POST, DELETE, etc.)

Ultimately, whether interacting with a human or another system... a well designed interface benefits both parties.

Behave, Deliver and Grow Like A Digital Company

Delivering digital interfaces to your organisation's customers, partners and employees is no longer optional. It is now essential for long-term effectiveness (and survival).

But this means unlocking the data, systems and functionality your business operates with and exposing this both internally and externally to meet increasingly shifting needs. But it is not easy... hardly any sizeable company has an entirely blank slate to work from. Legacy applications, processes and thinking tie any business down so that it can work well. But it is these very constraints that often limit speed and agility, which are needed to succeed now.

Digitally enabling your business means changing the way you behave, deliver and grow.

Behaviour:
Being customer focused means creating a better customer experience that can win and maintain custom in the competitive digital landscape. It also means understating and controlling your data, so you to make informed decisions quickly based on what you are observing or being told.

Delivery:
Start by using new platforms, tools and methods to build products quickly, plus then to evolve them rapidly over time. If you think your quarterly website functionality is fast now, consider that over 7 years ago Amazon stated it makes changes to production every 11.6 seconds (it may even be faster now) and Facebook releases to production twice a day.

Growth:
Don't be afraid to unleash the creativity and innovation within your boundaries to help you build. Employees must be part of the Digital journey (not observers) and everyone, not just your test manager, must work towards the continuous improvement of products and services.

Wake up and smell the data

Does your organisation value data?

Does it know how much value there is in each customer account & interaction it records?

Does it really appreciate that the timeliness, accuracy and depth / richness of the data captured stored or created has competitive advantage?

No... I didn't think so, and I'm pretty sure most other organisations don't either.

That's a shame. 

Evolution doesn't care how good or big you once were

I believe that is was Charles Darwin who stated “It is not the strongest of the species that survives, it is the one that is most adaptable to change”

But this fact is not only relevant to organisms, it also now applies to organisations. This means that the rate of change in customer expectations, technology and even the competition now means that being "agile" is not a strategy... it is essential to long term survival.

And I'll make a prediction...

"The rate of change in your company right now may seem like a sprint, but it will seem like a leisurely stroll compared to what's to come".

Or to put it even more bluntly...

"Hang on kids, this ride is about to get faster and there's no point screaming about it." 

So what happens to those organisations that don't adapt quickly? Well they won't perish overnight. But recent history has told us that those who believe their current business model or state of their technology/product/service is competitive now could swiftly find out things are less than good enough. And just like living things, it only takes a generation to go from being the hunter to the hunted.

Just look at how some retailers have failed to embrace technology: book shops, department stores, video rentals, etc. have all collapsed as digital services quickly ate their lunch using innovation or fast iterating software (or both). Digital evolution doesn't care how good or big you once were.

Agility not size is what matters now for corporate survival.

API's with everything

If you work in and around any sort of company that is undergoing a digital transformation, you will almost certainly hear the term "API".

Short for Application Programming Interface, put simply it provides a way for one system to be used by another in an agreed way. In other words, you can run some specific functionality or process elsewhere (e.g. within you organisation or across the Internet) via a set of published instructions.

APIs aren't a particularly new idea (I've been working with them since the 1990s), but they have grown in prominence and usage as other technologies and approaches such as Digital and SaaS (software as a service) have become more popular. It is therefore very likely that at some point or another most large organisations will have built APIs for their customers, or for their internal use.

Some  might therefore possibly state that we have currently "reached peak API use"... were it not for the likelihood that API development and adoption is set to increase further as more companies look to standardise and expand their digital integration capabilities.

It is also one of the reason's I called our company "Ideal Interface".

API granularity

Deciding how to design a digital architecture that provides optimum agility and scale-ability for your organisation is a challenge for many architects in the midst of a digital transformation. Deciding if you should use APIs in your integration layer is perhaps much less of a dilemma (hint: of course you must). But then working out how to design those APIs and the services behind them can be a new problem to solve.

I think this is an especially important decision, as it is quite hard to undo an architectural choice. Issues, can subsequently occur such as:

• performance bottlenecks (e.g. from too course a design)
• too much 'chatter' (e.g. from too granular a design) 
• the inclusion of too much (any?) business logic

All of which could have major implications in the future.

An agile mindset is not optional

Agile seems to be one of the most over-used words in business these days. For example:

Agile development 

Agile marketing

Agile architecture too ;-)

Done well, agile can produce prototypes and products very quickly and efficiently.

Done badly it can be an excuse for reducing the amount of time to create quality software or as a justification for only delivering partial functionality (for all of the budget).

Overall though... agility is a mindset, a way that organisations approach the task of creating value or improving the processes and products they have. And those that do not apply agility to their core will find they are not able to respond quickly or well enough to an increasingly swift competitive environment.

Or put another way.. which company wants to states as their vision or values that they want to be less reactive and more long-winded?

The Agile Architect

The technical or solution architect who has to align to an agile delivery methodology has a lot on their plate. In fact I have even recently written a post on The Agile Architect's Dilemma on Linkedin about the internal tug-of-war I am having between my agile and architectural approaches.

3 key areas they have to consider are:

Scale-ability / Scaleability:
To a certain extent this issue has become less of an issue with cloud-based services that have elastic capabilities to grown on-demand a volumes increase. However bottlenecks and latency can create problems, especially when using multiple different cloud providers or when API's are large & painfully slow. In short, not everything scales easily or linearly.

Micro-services / Microservices:
Rather than have monolithic points of integration (e.g. the above mentioned large APIs) the services that connect your different systems should be light and just based around specific functions. These micro-services allow incremental change and improvements to be made over time and better supports evolving front-end user experience requirements too.

Central data source:
Almost inevitably a digital architecture will need to store data in a single and centrally-hosted data source (e.g. a database). This repository of customer and operational data will need to be flexible enough to accommodate growing changes in storage and real-time data access requirements. However, no database (especially optimised relational database systems) can be expected to constantly change as the input and output demands of an agile development change too.

Customer Data Platform - Some Key Requirements

There's a growing trend in the digital industry to create or use Customer Data Platforms (CDPs). I will be hopefully covering this technical solution in future posts. However in the meantime iIf you are looking to implement one, here are some key (technical) requirements to consider:

• It provides a central unified customer data repository
• It allow simple / easy integration from a range of different data sources
• It supports a decoupled digital architecture, ideally via web services architecture
• It is able to elastically scale as demand and integration needs grow
• It is is resilient e.g. it provides fail-over (cold or warm) to separate disaster recover locations

The 7 myths of Search Engine Optimisation - Part 2

Part 2? Have you read Part 1 first?

Here's the second part of my post on the myths of SEO:

SEO can be done once and then stopped (even if you’re top ranked)
I can imagine many people reading this are saying to themselves.. “Hayden, you’re an SEO consultant. Of course, you’re going to tell us that you’re still needed once you’ve done your job”. However (with some poetic license and a very high-level perspective) there are only 4 factors that affect a website’s organic positions:

1. What goes into creating it
2. What other sites link to it
3. What changes the search engines make
4. What your competition (or their SEO agency) does 

Each of these could change on a daily basis. You only have some control over the first item (the content, code and other technical things), a little control over who links to you and then no control over the third and fourth factors.

Or more succinctly put… whatever search engine ranking position you have today (and yes, even if you have managed to get to the top) may not be the one you have tomorrow. And with no effort devoted to maintaining what you have achieved, it is increasingly likely that you will drop in the rankings just as quickly as you rose.


Ranking is the same for all users in all locations
There used to be a time (a long while ago) where you only got one set of global results from a search engine. Then things improved and now, even for the same brand of search engine (Google, Bing, etc.) you get different results if you are:
- In a different country
- In a different town
- Logged in to your Google account
- On a different device – see below
Note: This does make life difficult for SEO people who have to tell clients “I know you think you’re not on the first page, but you are on my device” or vice-versa.


Desktop and Mobile versions of Search Engines rank sites the same
No. They. Don’t!
And now… if you think you’re able to get away with creating a responsive website that shows just the same heavy images in desktop view and in mobile view, but just scaled down using the browser… as of this month, you’re probably going to get a surprise.


SEO is a ‘black art’ practiced by techies
Sure, there is a certain amount of technical optimisation that must now go in to any organic improvement piece of work. But there’s loads you can do as part of your marketing or PR day job for SEO.
1. Write articles you want to read & share, on topics relevant to terms you want to place for in the search engines
2. Structure your content to make it scan-able, readable and understandable.
3. Ask for links back to your website from partners, suppliers, journalists, etc.
4. And finally, stop believing in SEO myths

The 7 myths of Search Engine Optimisation - Part 1

Recently I had to give a presentation on Digital Marketing to a client. One of the key slides we focused was on the topic of “SEO Myths”.

I have therefore decided to write these myths up a post for others to add to and discuss.

Reaching 1st position in Google is the only aim of SEO
This is wrong advice in a couple of key areas:

1. What terms are you actually focusing on? If you’re either striving for a top place ranking on an obscure term or alternatively trying to be top for everything… think again. You should be looking at those terms that meet your KPI’s (e.g. deliver conversions) and have enough search volume to justify the effort of attempting to reach first place
2. Sometimes 2nd (or 3rd, etc.) place is good enough. If you’re targeting a popular search term and have reached the first page in Google, but there are bigger, more reputable and faster sites above you, you might be content with that (especially if it gets you decent & quality traffic)

A single teenager in a bedroom can out-smart Google
You still hear this sort of phrase spoken by people in the marketing industry “I know a genius, they have worked out how to ‘beat’ Google and get my sites to number one”. And each time… I feel myself suppressing a small scream. Why?

1. Just one person (who does not work at Google) who has only amassed knowledge from reading books, blogs and other such material on the subject of SEO knows everything on the subject.
2. Google hires offices full of very (very) clever people… many of whom have PHD’s and such qualifications, to constantly revise their search algorithms and the influence of different ranking factors. And even most of them don’t know everything on the subject.
3. You never ‘beat’ Google. It’s not a fight or a race… SEO is both an art and a science to getting your website legitimately up the rankings of the most popular western search engine.
   (and even if you temporarily manage to boost your rankings via less-than-legitimate means... there's a chance you'll get found out)

You can ignore SEO by just creating good content
OK, yes the creation of well written content helps SEO. But that content must also be:

• Relevant: Or else you’re just producing off-topic copy that serves no optimisation purpose 
• Structured: If you’re not adding layout, headings, bullet points, etc. then you’re not producing content, you’re just typing. 
• Linked: Are you creating lots of ‘orphaned’ pages to drop visitors into from other campaigns such as email PPC, etc.? Please don’t!

What's in a name?

"So why did you name your company Ideal Interface?" is a question I have heard quite a lot in the 11 years since it was founded.

This article may explain:
https://www.linkedin.com/pulse/why-ideal-interface-hayden-sutherland/

Digital Architecture fundamentals

As part of a recent project, I was asked to come up with some architecture fundamentals of a digital system (not just a one application system, but a more complex and integrated solution assumed to be for a larger organisation).

Here’s my list:

• The architecture of a system or integrated systems needs to align to (or fit into) the overall ‘As-Is’ and ‘To-Be’ enterprise architecture of your organisation.
  
• Those creating the architecture need to first understand the business goals (e.g. the customer experience and commercial aims) and the major applications that ‘the business’ are likely to need in the medium term or have signed longer-term contracts with.
  
• A loosely coupled architecture provides the flexibility to use best-of-breed solutions from a range of vendors. The opposite is that either through design or legacy system adoption, your architecture shackled to one key supplier who is then possibly also integrated directly to multiple other systems… this obviously creates a dependency upon this key supplier, making them harder to subsequent remove and replace. Adopting a loosely coupled architecture also means you are not tied to specific front-end software, allowing your organisation the flexibility to either buy or build (typically using agile product & developers) to create the best user experience possible.
  
• Where possible, create a single in-house database, that can be updated by any other integrated systems… ideally in real-time. You don’t have to store all data that exists in every other integrated systems in this central repository, just those that you may need to align other data to at some point in the future.
  Note: It is possible that this service could also be provided as another integrated system, but for overall speed, agility and ultimately data ownership you may find it best that this database sits within the boundary of your main architecture. However, this does come with additional considerations: there is an overhead in managing and administrating a significantly large database, plus the data model used needs to be sufficiently flexible and scale-able to handle a variety of requirements over time.

Can your site cope with sale volumes?

Right now the Marks & Spencer website is saying it is unavailable.

The M&S sale has started today. But it is not even possible to look (let alone buy) their products online.

Digital Agility Needs A Digital Core

The ability of any organisation to remain flexible and adaptable to changes in market conditions, improvements in technology and evolving customer needs is now becoming essential. Outdated business models, approaches and products & services no longer keep a company competitive and ultimately successful.

Having the ability to swiftly deliver and manage rich online experiences and digital functionality across multiple channels and touch-points is almost mandatory now.  But this requires a core digital core architecture that allows Information Technology providers (either in-house or as vendors) to respond quicker and quicker.

Note: It also requires a change in the organisation's mindset