A couple of months ago, I went thru an SEO audit. I wanted to write a blog post to reflect on what I learned. This is my feeble attempt to collect my thoughts and jot down some notes. Where available, I’ve tried to list my source links.
What is an SEO audit? In an audit, your website is analyzed and checked (often by an external SEO specialist) to be sure that it complies with SEO best practises.
12 items to consider:
GWT is your best friend.
I spent a lot of time working my way thru Google Webmaster Tools, cleaning duplicate title and meta description tags. Duplicate title tags are a negative quality feature for Google. Sources of duplicate title tags are
non-translated title tags,
content management software settings, e.g. showing the same mono-lingual Drupal view in several website languages.
GWT is the place to find these. Same for missing title tags. Or meta descriptions that are too short. Or the index status, which shows you how many pages are indexed.
Follow a holistic approach. If you think you’re all set ‘cos you have had your new web design and navigation tested for usability by a user experience expert… Think again. You need to involve SEO early on in your design project. Ask for SEO guidance once you’ve gone thru the card sorting/information architecture steps. Check your designs from an SEO perspective. Write content in close collaboration with your SEO analyst.
Question the SEO impact of new website features.
Ask your web developers about the SEO side-effects of adding new features and changes. I learnt that website changes to make a website responsive and mobile-friendly may add unintended SEO problems, e.g. ‘cos the changes added a second hidden navigation which Google cannot identify yet.
Ignore SEO noise.
A lot of the SEO advice that you read on the web is blabla. Avoid link-bait. Hearsay. Look for reputable sources and SEO specialists that really know their field.
Use the hreflang tag on multilingual websites.
Add rel="alternate" hreflang=x on all web pages.
Check the correct usage of heading tags.
Use only one h1 per page. Keep the order h2, h3, or h4. Don’t jump to an h3 after using an h1.
Check thru the design elements (e.g. navigation, footer, search button, contact form heading, teaser text blocks, or similar for hidden h1s or h2s).
Improve h1 content.
A heading 1 should provide a good summary of what to expect on the web page. Include keywords.
Add relevant internal links. Add an on-page sitemap. Use footer links for important landing pages, not to repeat the navigation. Never use any hidden sub-page menus. Make sure you use dropdown menus that can be parsed by Google.
Clean up any 302 redirects that may have been added by the content management system.
Check the XML sitemap.
The XML sitemap should only include pages with status code 200. Use the real, final URL in the XML sitemap, not the CMS page ID.
What will an SEO audit look like in 10 years? That is an intriguing question. I have no idea which way SEO will go. My guess is as good as yours. I do know that SEO is getting quite complex. And may even be replaced by *something* entirely new. If you are a website manager, my advice is to dig in and ask lots of questions.
Look at all aspects. Take a holistic approach. Try to form a cross-functional team (designer, ux researcher, web developer, SEO expert, content writer).
If you do search on Google, remember the search engine result on page 1 is not necessarily the best content, but the best optimized content. Use Google search operators to get you off the beaten track. And there are alternatives like DuckDuckGo and Wolfram Alpha, which we should support more to avoid monopoly and manipulation.
Some notes and photos from Saturday’s UX camp in ZÃ¼rich:
Adrian Sameli took us thru the process of building infographics. His tip on tools to use: Excel and Adobe Illustrator. He tried one or two infographic tools but didn’t like them much. In the discussion we looked at d3js.org.
Next, I attended a session on atomic design. Design systems not pages.
Developers need to agree early on with designers on the semantics of the smallest, small and medium building blocks. These then are used in templates to build pages.
The discussion after the presentation got straight to the daily challenges. Questions like
How do you get developers to use the existing pattern? Nobody reads documentation. In an ideal world, developer and designer sit in the same room and discuss the initial elements and define the markup. In real life the UX team may be much smaller than the developer team and might be geographically distributed, etc.
Is anybody using Pattern Lab in real-life projects? Very few projects get paid to build a pattern library. Pattern Lab is really more for larger projects due to the effort involved. How can this be improved?
Main idea: Often you see some obvious problems in your UX design after your first or second test person. Instead of going thru the whole test with the remaining test participants, change the prototype with your improvement between tests. And then continue testing your changed prototype. Main requirement: Designer needs to watch the user test. This shortens discussion time afterwards. Tools used: Sketch and inVision.
Don’t change too much. Follow Medlock’s classification.
Want to try RITE? Start with the traditional method first. Only use RITE after you have gained some experience in carrying out user tests.
Prio 1 obvious cause, quick solution, implement the fix and test with the next participant.
Yesterday morning a cyclist decided to cycle thru one of the roundabouts the wrong way round. During early morning traffic to work. If you’re thinking probably a bicycle courier: This cyclist was a woman in her 30s or 40s.
Nothing happened. No accident followed.
But it still had me shaking my head. Road traffic rules are there for our own safety. A lot can happen at 30km/h. We’re vulnerable. More than we think.
There are enough occasions when we make unintended mistakes. No need to wilfully ignore traffic rules.