7 Optimisation issues to check in your next SEO Audit
Estimated reading time: 4 minutes, 15 seconds
Although there already are amazingly complete checklists including the different aspects to verify when doing SEO audits, –like Annie Cushing’s Craziest Audit Checklist on the Internet–, I would like to share some of the issues I’ve lately found to be more common or that could really hurt our SEO efforts if not implemented properly, so you can also keep your eyes open for them, as I do, especially in some specific scenarios:
1. Canonical tags pointing to old URLs
When your URLs change, whether due to a migration or when you optimize them to become more relevant, make sure not only to validate the 301-redirects from the old to the new URLs, but make sure that the canonical tags of the new URLs are also updated. Screaming Frog is handy to validate this error easily.
2. Internal links going to non-canonical URLs
Sometimes links from a site navigation are not correctly configured and instead of going to the original version of the URLs they point to those that are 301-redirected to the original ones.
This tend to happen again when you change your URL structure, forgetting to update some links from the menu, breadcrumb, paginations, etc. that are still going to the old URLs, or more simply due to a non-optimal CMS configuration (eliminating the slash at the end of the URL or the www from the beginning, despite that the original URL versions are including them). In this case, you can use Screaming Frog again to crawl the site and look for those “unnecessary” 301 redirects.
3. XML Sitemap includes non-canonical, non-existent or blocked URLs
Verify if your Web platform “automatically” generate your XML Sitemaps including all of your internal pages, as well as additional elements, like images or videos, by default, instead of allowing you to configure that only the original versions of each page, images and videos are featured.
I’ve found many cases where elements that were even blocked by the robots.txt and were not meant to be indexed had been included “by default” in the XML sitemap or that some of the crawling errors of the site were caused by non-existent URLs that had been “automatically” added in the XML sitemap:
4. Hreflang annotations don’t feature a correct value
Many multilingual sites have already started using hreflang annotations to specify the language of their content and the country that they’re targeting, nonetheless, some of them are not using correct values in the tags, as it can be seen in the following example taken from the Nerdy Data results for the sites including hreflang=”en-uk” instead of hreflang=”en-gb”, that is the correct value in this case:
To avoid these issues I’ve published a tool to help you generate hreflang tags including the correct values for each selected language and country.
5. The Mobile Subdomain is Blocked
Some sites that have a parallel mobile site structure, featuring separate mobile URLs, usually under an “m” subdomain, block its crawling entirely through a robots.txt, not realizing that they’re losing the popularity given by many incoming links, as happens with Flickr in this example:
In this case, instead of avoiding content duplication issues by blocking the subdomain entirely, what is recommended is to allow the crawling and indexing of the mobile targeted URLs and use the rel alternate and rel canonical annotations as recommended by Google, to refer between the desktop and mobile URLs:
6. No rel canonical & alternate annotations in parallel Mobile websites
Speaking about the rel alternate and canonical tags for a parallel mobile Web setting: Make sure to always include them as shown above. Unfortunately not all of the sites with parallel mobile versions do this, like in the Zalando example below. You can alternatively feature the rel alternate annotations in your desktop Website XML sitemap, as specified at the end of the Google mobile recommendations here.
This is important to include as you might end-up having content duplication and cannibalization issues in the search results between your mobile and desktop URLs if you don’t inform Google about the type and relationship of your Mobile and desktop pages.
7. No redirects to the Web version of the relevant device
Another very important aspect to verify when doing an SEO audit for a site that has a parallel mobile Website is that it doesn’t only redirect Mobile users (and crawlers) to the relevant Mobile URL when they arrive to a Desktop URL, but also 301-redirect Desktop users (and crawlers) that arrive to a mobile URL.
Beyond SEO, think about the user experience, for example, if I’m shared a Mobile page (by someone that was browsing from a Smartphone) and I’m not redirected when I open it in my laptop, as happens in this case with Booking:
The same happens with other important Websites as Zalando or The Atlantic, that still show their mobile version to users accessing from desktop browsers:
In this case, it’s recommended to implement 301-redirects to always show the appropriate URL version according to the used device: