This is another area given short shrift in many ecommerce projects and I just can’t figure out why! The ‘SEO is dead/content marketing is the new SEO’ brigade is quite simply wrong.
Until I see evidence that organic search isn’t a key traffic/revenue/brand channel for ecommerce, I’ll keep ignoring the hype. Every website I work with generates somewhere between 30% and 70% of all traffic from organic search.
Yes, other channels contribute as organic isn’t always first/last click but search engines are still the number one tool for consumers to find information and products.
OK mini rant over, soap box put away…
So why is SEO vital for your IA?
Because if you don’t think through the impact of your development decisions on your ability to get webpages indexed for relevant keyword searches, you’ve compromised your online marketing from the start.
And for what? To save a few £k investment upfront when the opportunity cost is far, far higher.
The best example is technical SEO. Typically the technical implementation decisions are left to developers who may not fully understand the SEO implications of the decisions they take on site architecture and development.
Technical SEO skills have become increasingly important because search engines like Google factor site performance into their algorithms.
Technical SEO is often an afterthought in the web development process, usually considered after the website has gone live. The truth is that most of the issues that get flagged in a technical SEO audit can be avoided if they were considered in the early stages of web development.
I can highly recommend reading Econsultancy’s SEO guide, which has a section on technical SEO written by Lisa Myers of Verve Search and Chris Evans of SEMetrical – they both have an incredibly detailed knowledge of technical considerations.
[Disclaimer – I helped write and edit the report. This isn’t a shameless plug, the other contributors are some of the brightest minds in UK and International SEO and I learnt a lot from reading their content].
- The rules for the generation of page titles, meta descriptions, URLs and H tags.
- Redirect requirements for domain versions e.g. is primary version http://mydomain.com and the www. version redirects to this? Or vice-versa?
- How you will use the canonical tag to reduce the risk of content duplication.
- Which pages you want to be indexed and which you don’t (using the noindex tag).
- Which internal links you want to be followed by search engines and which you don’t (using the nofollow tag).
- How you will use pagination for product pages and the use of ‘rel=previous’ and ‘rel=next’ tags and/or using the canonical tag on a “View all” page.
- What URL parameters the website will generate and how you need to manage these to control indexation issues.
- How you will use 301/302 redirects and set-up the systems to enable you to create these without additional development work.
- How you will use the robots.txt file and ensure this is easy to access and edit on the fly.
- Which sitemaps you need, how they will be created and automated to ensure they are always updated.
- Your 404 error page (soft and hard) and ensure it provides relevant links back to the website.
- Search friendly file names for content assets like images and ensure there are alt tags.
- Rules for any blog content on the website e.g. will links in comments automatically have the ‘nofollow’ tag to avoid link spam?
- Opportunities for using relevant mark-up such as authorship and reviews.
It’s not an exhaustive list but it gives you a good rallying point.
6. Integration of non-product content
You’ll be surprised at how much effort can be involved in retrospectively integrating non-product content into product pages.
For example, on a PDP, if you want to link to related buying guides, where do you put the links? How does this affect the existing content flow? How do you automate the links appearing so it’s data driven, not manual?
It pays to sit down and think carefully about where on the site your users would expect/need to find relevant content to help them make decisions. You can then map out all page templates that need to be designed with this information requirement in mind, for example including blog content on search results pages.
The example below is from Australian retailer Adore Beauty. It surfaces discussions, articles and social content alongside products on the search results page.
There are several ways to structure the data to enable this. One option is to configure the CMS so that when a new content asset is uploaded, there are required data fields that need to be set before the upload can be processed.
For example, you could select categories to associate the content asset with from the product catalogue, so that for each category you select, the content asset will show on that category page in a pre-defined content zone (which could use a carousel to enable users to browse multiple assets, or use a business rule like “show the most popular” to ensure the content is kept fresh).
- Define what types of content you want to surface next to products e.g. buying guides, articles, blogs etc.
- Identify which page templates you require this to happen on.
- Define what data you need to store against the content assets to help automate the presentation on product pages.
- Make sure your data systems are set-up to capture this data.
- Define business rules for the presentation of the content e.g. only show blogs from the last 30 days.
For example, if each content asset sits on its own unique webpage, you may decide to use the meta keywords property to insert keyword relevant tags e.g. jeans / denim for a buying guide on men’s jeans.
A script can be added to the PDP that matches the product title with the meta keywords property, so that a product called ‘Men’s Skinny Jeans’ will return a match for the buying guide but ‘Men’s Cashmere Scarf’ will not.
Some websites also make use of the meta keywords property for generating site search results pages, so you can kill two birds with one stone.
I appreciate that this is a whistle stop tour and in reality there is far more detail involved and a lot more elements to consider but hopefully this gives you food for thought.
Creating an IA for ecommerce is a critical element of your project and it needs to be a constant work in progress, updating based on the evolving needs of the business and your website users.
My recommendation is to give someone ownership of this and make sure it’s clearly documented, then use version control to update the master document over time.
For those of you who missed the previous blogs:
- Part one is on site & catalogue structure.
- Part two is on URL structure & data formats.
What do you think? What tips and tricks have you got to share to help others plan their information architecture? I’d welcome your thoughts and suggestions.