Chapter 3: Magento 2 – Advanced SEO Fixes

The Guide:

This Chapter:

Introduction

Magento 1.9.x had several SEO flaws out-of-the-box that required a small amount of development or the use of extensions to fix them. Unfortunately, many of these are still an issue in Magento 2.x.

Please note, this chapter does not cover every outstanding issue with your Magento website. Many of the SEO issues with your site will relate to how it is used or misused. Some of these issues are common to other eCommerce platforms, so will not be discussed here.

This chapter focuses on fixes that need some development or commercial extensions to implement in Magento 2.x. Where possible, we also included details of how to fix each issue in Magento 1.9x.

Some fixes such as extended server configuration and optimisation will be covered in a separate chapter.

Note: Click on the icons to get extended information and the rationale behind each change or click here to show them all.

Faceted Navigation

Faceted navigation (or category filters) is one of the most common sources of issues with eCommerce websites. Unfortunately, Magento 2.x is no different.

Crawlability

Faceted navigation is a challenge on eCommerce websites because it has the potential to create endlessly crawlable sites. Looking at a Magento 2.x category page:

magento2-category-page

The faceted links on the left (above) would link to:

  • /women/tops-women/tanks-women.html?style_general=140
  • /women/tops-women/tanks-women.html?style_general=144
  • /women/tops-women/tanks-women.html?style_general=151

Every product attribute on the site creates a new potential URL – this would be multiple new URLs since attributes can be combined.

Why is this a problem?

Google has never explained why this is an issue directly, but we do know that;

  1. Google wants to give users good search results.
  2. Google cannot crawl EVERY page of your site EVERY day (see below) because it would put stress on your web server.

Consequently, each website has a “crawl budget”.

In general, sites with more pages and more authority will have a larger crawl budget than less authoritative sites. Google is intelligent at prioritising which pages get crawled and how frequent, but it is not perfect. By creating filtered pages, more pages must be crawled and consequently important pages (such as product pages and categories) can be crawled less.

Crawlability is a ranking factor?

SEOs believe that Google may favour freshness as a factor for eCommerce. If Google is sending users to a product page, remember that product pages can go out of stock quite easily.

If your website is out of stock of a product, users may be unsatisfied with the results that Google has given them, especially if your site’s response code to discontinued or out of stock products is a 404 error page. If this continues to happen over a period of time, then Google will start to rank your website lower, as it will recognise that users are having a poor experience on your website.

To summarise, Google may promote product results from sites it has very recently checked. Creating lots of extra pages reduces Google’s ability to frequently check those pages. Faceted navigation creates lots of pages that must be checked.

In the previous chapter, canonical tags were set up on the category page. This partially helps solve another aspect of the issue faceted navigation causes but does not prevent Google from still needing to crawl these pages.

Google published a blog post on the best practices for faceted navigation in 2014. We recommend two approaches.

Approach 1: Two facets and you’re done

This is only a good idea if you need the filtered attribute pages to be indexed

In this approach,

  • You allow users to specify the first filter. This leads to a page with the remaining faceted options.
  • Users can select a second filter. This leads to a page with no faceted options but instead a “refine further” form as an option (see below). This is similar to what eBay has done.

This overall approach (with effective configuration) reduces the amount of potentially indexable pages from millions to mere thousands. This method should be used with caution.

Planning for this scenario is necessary if your site is using some sort of “Search Engine Friendly” extension that turns an attribute like:

/women/tops-women/tanks-women.html?color=50

into something like

/women/tops-women/tanks-women/colour-blue/

This can be done using an extension such as BubbleShop Layer Pro (Magento 1.9.x) or Amasty Improved Layered Navigation.

Note: These plugins cause their own issues both for performance and SEO, so should only be used in tightly controlled circumstances.

Implementation

Implementation involves development; however, some of the extensions that implement these pages can also be configured to work in a Search Engine Friendly manner, e.g. Amasty Improved Layered Navigation – but this requires extensive setup.

Configuration of Amasty Improved Layered Navigation varies from site to site and will need to be actively maintained as new categories are added to the site. The effective configuration goes well outside of the scope of this document. The “easiest approach” recommended by Amasty themselves is a great starting point although advanced users will need to look at some of the following:

  • Attribute filters must be configured to reduce the number of pages created.
    • Some attributes will need to be excluded from this process e.g. ratings, prices, size.
    • This results in URLs that are a mix of Search Engine Friendly URLs and query strings that canonicalise back to another page.
  • Category exclusions / inclusions must be configured. For example,
    • Where filters would create duplicate pages (e.g. www.example.com/brand/product-category/when www.example.com/product-category/brand/ exists).
    • Where there is no SEO benefit in creating a page (a combination of attributes that has zero search volume).
  • Default SEO settings and tweaks are necessary (manually specifying certain tags).

Disclaimer

This approach is discouraged because of the sheer amount of thin or high duplicate (or low quality) content these extensions create. If this is required, a strategy will need to be in place to deal with this and any performance issues caused by these extensions.

Some popular strategies to deal with this thin content include using;

  • Category descriptions (generated or manually written).
  • Featured product reviews or featured products.
  • Curated lists of recommended products.
  • Links to content (buyer’s guides, FAQ).
  • “Recent comments / questions”.
  • Selectively no-indexing or using canonical tags to ensure that combinations of filters that do not have search volume are not indexed, e.g. weight, price or those found to have zero volume using Keyword Research.

Approach 2: Nofollowing faceted navigation

In most cases, this is the best approach. No-following at the link level means changing the HTML in a link from something like:

href=”http://www.example.com/candy/?filter=3334>Chocolate</a&gt
<strong>rel=”nofollow”</strong> href=”http://www.example.com/candy/?filter=3334&gt;Chocolate&lt;/a&gt

This is a simple instruction to crawlers – don’t crawl this link.

Magento 1.9.x Nofollow

In Magento 1.9.x this required a small update to the filter.phtml and state.phtml files in order to add a no-follow tag:

App / design /frontend / {your template} / template / catalog / layer.

Magento 2.x Nofollow

In Magento 2.x it seems quite similar, with the view for the faceted navigation located at:

App / design / frontend / {your template} / Magento_LayeredNavigation / templates / layer / view.phtml

Other Links That Can Be Nofollowed

Other Magento 2.x pages that do not need to be crawled include the following, and can safely be no-followed;

  • The checkout cart / login pages,
  • Send to friend links,

The above situation is identical in Magento 1.9x, although links to the following page types also benefited from no-following:

  • Add to wishlist,
  • Gallery,
  • Product Compare,
  • “Add Review”.

This is unnecessary in Magento 2.x because these types of pages have been implemented in a different way. Other common sources of crawler loss, include calendar extensions and printable versions.

Note: Page pagination and links to proper categories / sub-categories are fine to be crawled, but they should not be nofollowed.

In May 2016, a Google Hangout with Google’s Gary Illyes indirectly contradicted some of the recommendations from the 2014 Google Webmasters Blog. No-following links to non-indexable pages remains a recommendation until this is clarified.

Thin / Duplicate Content

Thin and duplicate content is a common problem on eCommerce sites. It roughly means “content that does not add much value”, although a more detailed description is below.

Google Panda

The history of SEO (1998-2011) is the history of people discovering ways to exploit search engine rankings. At one stage, SEOs realised that the more pages you had, the more things you could rank for.

Creating more pages meant that each page could be optimised for a specific keyword and would, therefore, have a better chance of ranking for that particular term. In practice, this meant that as well as having a page for “Blue jeans”, you could create a category page for;

  • Cheap Blue Jeans,
  • Best Blue Jeans,
  • Blue Jeans in Manchester,
  • Blue Jeans in Liverpool,
  • Cheap Blue Jeans in Manchester,
  • … repeat for every city in the UK.

Predictably SEOs spammed the hell out of this tactic and created thousands of pages of duplicate and low-quality pages. It also required no effort since these pages were generated programmatically.

This meant that users were served up results from poorer sites just because they were slightly more relevant. Google called these pages doorway pages – pages that are set up just to increase the number of keywords your site ranks for without any real benefits to them.

Why is this a problem?

In 2011, a Google update reduced the visibility of pages like this with an algorithm update called “Panda”. It has since been revised and iterated over time.

Originally, SEOs believed that sites with high amounts of duplicate content were being penalised – not for one term – for every term. Think of it like this:

  • Your site’s quality is like the denominator in a fraction. Your links, relevance, technical SEO and content are like the numerator.
  • Ranking = (links + content + technical SEO) / site quality (as a percentage).

Entire sites were wiped out of the search results by being classed as low quality by this algorithm.

Note: The update was not really targeted at eCommerce sites, it was targeted more towards content and information sites, but some eCommerce websites were still caught in the cross-fire.

The algorithm was significantly more sophisticated in 2016. Google has invested heavily in machine learning and most SEOs agree that it is less likely that “non-manipulative” duplicate content (individually optimised pages) will cause your site’s “quality score” to suffer.

In fact, Google has confirmed this publically. This now means that:

  • At worst, certain high duplicate pages will just not be indexed,
  • Pages containing significant externally duplicate information (e.g. manufacturer’s product descriptions) without adding much value may become demoted in the search results.

So, What Now?

We have to rely on Google’s algorithms to understand that any duplicate / thin content on your site is not manipulative. This is not something you can be certain about.

Secondly, some configurations of your categories / faceted navigation may actually be manipulative – particularly when third-party extensions are used that turn those faceted navigation pages into optimised SEO landing pages. It is important to be careful of what third-party tools you use and be careful not to appear as if you are trying to manipulate Google’s algorithms.

Fixing duplicate and thin content is, therefore, a way of mitigating risk and promoting indexation of your important pages. It will sometimes have benefits for your site’s quality.

Magento and Duplicate Content

Magento’s faceted navigation, like others, does create duplicate content. E.g.

  • /women/tops-women/tanks-women.html?price=30-
  • /women/tops-women/tanks-women.html?price=30-&product_list_limit=30

The basic SEO setup we discussed in previous chapters added special tags to the Magento category pages to ensure that these filter pages are “canonicalised” to the category page that created them. This means that a tag is inserted that indicates to Google that this page is merely a duplicate of the “main” page and tells Google not to consider that page to be a duplicate.

Most of the time, this will be enough. Unfortunately, this tag can also be ignored by Google and those filter pages may be indexed as low-quality content.

This is because canonical tags are only a signal, not a directive. Google decides whether or not it listens to signals, whereas it always obeys directives, such as no-index.

Fixing Duplicate / Thin Content

The common fix is to block any URLs with a query string in the robots.txt. Unfortunately, this does not remove pages that are already indexed, so it is not good for existing sites.

Read Chapter 2 for the discussion around the Robots.txt file.

Another fix is to add a special tag (“noindex”) to category pages when filters are used. This is discussed below.

No-indexing in Magento 1.9.x

Creare actually had two ways of doing this in Magento 1.9.x.

No-ndexing in Magento 2.x

There are two commercial options for fixing this in Magento 2.x. Neither are currently free but both include a lot of extra functionality.

  • A version of the Creare SEO plugin is planned but Magento 2 version is not yet available.
  • Mageworx SEO Suite is available for Magento 2 at $249 (Community) or $498 (Commerce).

No-indexing Search Pages

Every time a user performs a unique search on your site a new URL is generated (e.g. example.com/?s=search+query). If not managed correctly, search engines can find and index these URLs which can cause numerous issues. It is worth adding noindex tags to internal search result pages – this is preferable to blocking these pages in robots.txt.

This can be actioned in either of the above plugins or with a small amendment to the search template.

Sometimes internal search pages will appear in search results and can perform well, but allowing Google to index these pages is generally believed to be a mistake for the following reasons:

    1. This is because these pages will often be thin or duplicate content.
    2. These search pages will include the searched keyword in the page title and heading as though they were optimised for this keyword, meaning they can compete with categories or product pages that are better suited for this keyword (this is known as cannibalisation).
    3. It allows junk pages to be created remotely, for example, users or competitors could get these poor-quality pages indexed for you or even ‘attack’ the website by causing thousands of pages of duplicate / thin content to be indexed by shooting links at these pages for Google to crawl.

We recommend you use the search term report in Google Analytics (if configured) or Magento to understand what search terms are popular and ensure that they have dedicated category pages which can be indexed. If categories already exist, improve your navigation to ensure that users use the menu instead of an internal search.

Pagination

This is closely related to the above topic. In 2011, Google introduced a standard to allow developers to mark-up pagination (categories with multiple pages, e.g. page 1 of 3, page 2 of 3, etc.). There is a handy blog post on this subject.

Pagination Code

This involves adding mark-up like

<link rel="prev" href="http://www.travellingman.com/graphic-novels/" />
<link rel="next" href="http://www.travellingman.com/graphic-novels/?p=3" />

Where appropriate.

Note: Google’s relatively good at detecting this on its own, but ensuring that this mark-up is present is another form of risk assurance.

This is easily fixable with some modifications to the head view when the catalog category is called, but it can also be fixed using plugins.

Magento 1.x Pagination

In Magento 1.9.x, this was something that was fixed by the handy Creare Magento plugin – it is a default setting.

Alternatively, Inchoo.net’s walkthrough accomplishes the same goal without the need for an extension.

Magento 2x Pagination

Similar modifications should be possible in Magento 2x, and several commercial extensions are available already which implement this.

  • The Mageworx SEO Suite Extension also adds this. A competing extension from Mirasvit is also available, but we are unable to recommend this without testing it ourselves first.
  • Alternatively, configuration of URL parameters in Google Search Console can achieve a similar effect without modifying the site. This is described below.

Configuring Magento URL Parameters in Google Search Console

If the above paths are not available, a good short term solution for both pagination and attributes can be provided via Google Search Console – via Crawl > URL Parameters.

And configuring the p parameter like the image below.

Other parameters that can be updated in Search Console include:

  • cat – narrows (Magento 1.9x / Magento 2x),
  • order – sorts (Magento 1.9x),
  • product_list_order – sorts (Magento 2.x),
  • product_list_limit – narrows (Magento 2x),
  • limit – narrows (Magento 1.9x),
  • price – narrows (Magento 1.9x / Magento 2x).

Additional parameters will be custom to your theme and the attributes they use.

Google’s Pagination Update

In 2019, Google announced that they will no longer look at rel=prev and rel=next markup for pagination. While this does remain the case, this does not mean that you should remove your pagination, as this can negatively affect your SEO.

If you have pagination set up, do nothing. This will not harm your performance, but removing it could. Leaving this in will simply be used as a signal to Google, and not a directive.

Despite Google’s statement, pagination is still recommended by W3C and used for web accessibility and ADA compliance. Some browsers also use it for prefetching. Also, other search engines like Bing still use the markup.

Canonical tags are a good alternative to pagination, and we will cover this next. Ahrefs explain how this can be effective without harming your performance.

Canonical Tags

Two issues exist with the standard implementation of canonical tags in Magento 2.x.

Canonical on CMS pages

While CMS pages have been substantially improved in Magento 2.x, looking at a demo site setup by PushON, we can see that CMS pages still lack a canonical URL. A common Magento 1.9.x issue was the homepage being duplicated at (for example);

  • http://magento2.pushonltd.co.uk/home/
  • http://magento2.pushonltd.co.uk/home
  • http://magento2.pushonltd.co.uk/

Canonical on CMS Pages in Magento 1.x

In Magento 1.9x, this was easily fixable using an extension (Creare SEO) or by adding this code to the page layout, revising the URL to reflect the page you desired to be the canonical URL for that page;

 <reference name="head">
  <action method="addLinkRel">
    <rel>canonical</rel>
    <href>http://magento2.pushonltd.co.uk/</href>
  </action>
</reference>

Canonical on CMS Pages in Magento 2.x

Overrides do not work in the same way in Magento 2, so this must be implemented using an extension or redirects.

  • Extensions that fix this include Mageworx SEO Suite ($249 / $498) or (for the homepage only) the Magento 2 Home Canonical Tag Extension (free) – prices correct at time of writing.
  • Redirects can be implemented in Nginx / Apache using the method described in the previous chapter (“Click For More Details About Forcing a Trailing Slash”).

Canonical Override On Categories / Products

One of the nicer things in Magento 1.9.x was the ability to override canonical URLs on products and categories manually.

Sometimes, duplicate categories would be created for logical reasons – for example,

  • http://www.example.com/led-lightbulbs/gu-10/
  • http://www.example.com/gu-10/led-lightbulbs/

To reflect how users may search for the same products in different ways – first by type of lightbulb, then by type of bulb socket – and vice versa.

Duplicate categories are also created via Magento’s multiple storefronts capabilities. For example,

  • Trade customer sites with special pricing – usually inaccessible to those without an account.
  • White labelled affiliate sites – hosted on another domain.

Magento 1.x Canonical Overrides

This could be resolved in Magento 1.9.x (on a per-page basis) by adding the following custom layout update to the Custom Design for that category.

<reference name="head">
  <action method="removeItem" block="head">
    <item>link_rel</item>
    <name>http://www.example.com/gu-10/led-lightbulbs/</name>
  </action>
  <action method="addLinkRel" translate="title">
    <rel>canonical</rel>
    <href>http://www.example.com/led-lightbulbs/gu-10/</href>
  </action>
</reference>

This would action an override, removing the default canonical URL and replacing it with the second. For large scale canonical overrides, development is necessary.

Magento 2.x Canonical Overrides

Manual overrides are no longer available in Magento 2.x, so it must be implemented using an extension such as Mageworx SEO Suite extension for Magento 2.

Alternatively, this can be implemented with a small amount of development. For example, by associating a text field as an attribute on products and categories which overrides the default canonical URL if specified.

Hreflang (International Markup)

Magento is well placed to handle international sites because of its multiple storefronts capabilities. This is a useful feature in Magento that allows you to create multiple stores within the same Magento installation. For example, you might have one storefront for consumers and another for wholesale.

Hreflang is (primarily) HTML markup which helps Google to understand when a page is available in other languages.

For example, if an international site has separate pages set up for English speakers in Australia, UK, Canada and USA, Hreflang helps inform Google which of these pages users in those countries should get from their local version of Google.

Another benefit to this is that it helps Google understand that each English version of the same page is not duplicate content.

Hreflang Technical Overview

Hreflang tags (read Google’s guidelines) use ISO 639-1 abbreviations to specify the language – e.g. en, fr, de, es – and use ISO-3166-1 tags to specify the country (if necessary) – e.g. US, GB, CA, AU.

They are combined together using a hyphen. E.g.

  • en-GB – English speakers in the UK,
  • en – All English speakers,
  • fr-IT – French speakers in Italy.

They must contain a language, specifying a country on its own is not supported.

This is implemented in 3 main ways:

  1. On-page markup – for example, the homepage of BooHoo’s Spanish site (see above).
  2. Use of extended markup in the XML sitemaps.
  3. Extra data in the HTTP response header when the page is served.

Example of Hreflang

Note: Hreflang is not supported by Bing – use of language attributes in the opening HTML tag will be necessary.

Implementation

Hreflang in Magento 1.9.x

If sites were implemented with multiple storefronts, which required a small amount of development and ensuring that the correct location was set for that storefront via:

Configuration > General > Countries Options.

As well as language (same page):

Locale Options

Then this development ensured that Hreflang links existed between each version of a product or category.

Although a commercial extension was available that streamlined the process (Multi-Language Alternate Hreflang SEO tags).

Hreflang in Magento 2.x

Similar development and similar methods will work to ensure that each storefront can be associated with a language via Store > Configuration > General / General > Country Options (and Locale) and selecting the correct storefront via Store View.

This is also implemented by the Mageworx SEO Suite extension for Magento 2.

International Redirects

If you are implementing international sites via Magento, it might be tempting to implement geo-based IP redirects. For example, redirecting from www.example.co.uk and www.example.fr to www.example.com if the user’s IP address is detected as a UK one using a geo-database such as MaxMind.

Please don’t do this.

Google’s crawlers are based in the US – and always based in the US. This means that methodology like this can make your non-US sites invisible to Google’s crawlers.

Our recommendation is that a geo-based modal is used if the user’s IP address shows that they are in a different country to the one intended. As long as their preference is remembered via a cookie, this is unobtrusive. The link provided should also be to the appropriate page – not just the homepage.

It might also be tempting to ignore the above and implement geo-based redirects, but exclude Google’s crawlers. Please do not do this either, as this is known as cloaking and is a violation of Google’s Webmaster Guidelines.

Internal Links/Breadcrumbs

The implementation of breadcrumbs in Magento has caused sub-categories to have poor internal links. Internal links are believed to be important for SEO. An explanation of the theories around this is below.

A historical theory relates back to the original concept of how PageRank (authority) was distributed around your website and the Internet as a whole.

1000px-PageRanks-Example.svg

In the classic model, your site’s authority was distributed by its links – authority was shared evenly amongst the pages that were linked. Pages with more internal links got more of the authority.

This concept is quite outdated now as Google’s ability to understand which pages are important has advanced significantly since 1997, but alternate theories exist.

More important pages on your site will have a greater amount of internal links to them. A navigation menu does a reasonable job of doing this for your main categories. However, these are believed to be less important than relevant internal links – not harmful, just less important than a non-sitewide link.

If we get onto some “silo structure” concepts, the relevance of a page can be determined both by the relevance of the content on it, but also by the relevance of the pages linking to it – both external and internal. In simple terms, a site about coffee will have lots of links to it from content about coffee.

On an eCommerce site, this happens with breadcrumbs.

Breadcrumbs SEO Benefits

Consider a product page for a felt tip pen. It may have breadcrumbs like;

Home > Stationery > Colouring > Felt Tip Pens > Back To School Fibre Tip Pens Pack of 10.

Where each of the above breadcrumbs links to the category (Stationery), sub-category (Colouring) and sub-sub-category (Felt Tip Pens) page.

A relevant/natural internal link for a category page for felt tip pens would be from a product itself. Since there will be multiple felt tip pens, each of those products will internally link back to the sub-sub-category page, theoretically indicating more of the site’s authority (for “felt tip pens”) should go to this page and creating lots of relevant internal links for that term.

So the SEO benefits of breadcrumbs are simply this. Breadcrumbs can let you ‘automate’ your site’s internal link structure.

Note: Larger sites will often have to manually refine it. For example, Amazon changes the navigation menus based on the section of the site, enforcing relevant internal links and allowing users to navigate the section of the site they are on more effectively, but most sites will not need this level of micromanagement.

Doesn’t Magento have breadcrumbs?

Unfortunately, breadcrumbs do not work like this in Magento 1.9.x or Magento 2.

Since a product can be in multiple categories, the breadcrumbs are stored at session-level based on how you navigated to the product. This is a problem when a user goes directly to a product page, the breadcrumbs in Magento 1.9x / 2 will be stripped, as shown in the example from MADE below.

Home > 2 x Flynn Dining Chairs, Persian Grey.

Whereas users will see breadcrumbs like;

Home > Chairs > Dining Chairs > 2 x Flynn Dining Chairs, Persian Grey.

At least on most Magento installations, this causes the following issue:

site-structure

Google will see the stripped version, as far as it is concerned, there are no internal links from the breadcrumbs. As you can see from the above graphic, the category and sub-category pages have very few internal links to them, typically from the category page.

With Magento 2 and 1.9.x, you have a choice between 2 options;

  • Duplicate products (no canonical URL on products) and semi-working breadcrumbs.
  • Canonical URL on a product that strips the URL to the root and non-working breadcrumbs.

Most people go for the latter.

The Solution

We have seen developers come up with various solutions to this, including using the attribute sets associated with it to internally link to the correct pages, but this is a bit of a hack and does not scale well.

In Magento 1.9x, there is a solution via an extension called Advanced Breadcrumbs, which forces the default breadcrumbs to be the longest path.

It also uses RDFa breadcrumbs, the oldest and best support markup for breadcrumbs (this is a very good thing!)

This creates thousands of internal links to your sub-category and category pages from the most relevant source – the products themselves. In theory, this is great for increasing rankings for those pages.

This extension is available in Magento 2.x at a cost of $69 (time correct at the time of writing).

Schema

Schema (“structured data”) is one of the more welcome additions to Magento 2 – provided developers properly extend this functionality. Unfortunately, there are several gaps here.

Offer Schema

The Offer Schema specification includes a reference for whether or not a product is in stock or not (offer schema is contained within product schema).

<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<span itemprop="priceCurrency" content="USD">$</span>
<span itemprop="price" content="1000.00">1,000.00</span>
<link itemprop="availability" href="http://schema.org/InStock" />In stock
</div>

This seems to have been intentional because the block where availability is defined (default) is outside of the Offer Schema block so adding:

<link itemprop="availability" href="http://schema.org/InStock" />

(or Discontinued, OutOfStock, PreOrder – see full list of ItemAvailability Schema) would be out of scope.

Solutions

In Magento 1.9.x, there are several free Schema solutions. These tend to use JSON+LD, so they are easy to implement into your site. Creare’s extension does this out-of-the-box.

For Magento 2.x, developers will need to shift the declaration of the Offer Schema into a containing div that encompasses both.

Product Schema

Product Schema is not necessary on category pages, but one benefit for doing so is that data from the page can be pulled into the search results, e.g.

However, even with the correct schema implemented, there is no guarantee that Google will choose to use this information.

SEOs claim the implementation of product schema can help improve organic rankings by allowing Google to “better understand the content of the page with greater certainty”.

In PushON’s experience, this is not 100% proven. However, we do know that click-through rates from the search may be improved, as users can more clearly see that the page has “lots” of products. In other words, the benefits are for humans rather than search engines.

Implementation of this requires some development tweaks to the category page.

Page Load Times

A fast loading page has conversion, UX and SEO benefits.

Image Optimisation (File Size)

Properly optimised images are a huge component of Google’s PageSpeed Insights test.

This primarily focuses on image file sizes and use of lossless compression.

google-pagespeed-insights-download

Lossless compression tools such as jpegoptim or PngOptimizer can reduce the size of images without a loss in quality. Similar tools should already be part of your development process so that any theme images are correctly optimised.

Google’s own lossless compression tool is not available as an API (as yet), but it is around 20% better than anything publicly available. However, files output from it are available to download from the above tool. Where possible, these should be manually used to optimise template assets.

Solutions

Magento 1.9.x had an issue when thumbnails were generated, typically with PHP’s GD. These files would not be optimised for file size, even if the source file it was created from was. This appears to be an issue in Magento 2.x too.

Solutions for this tended to be server based, usually a CRON job that compressed the images. If scheduled appropriately, this rarely puts too much stress on the server. Extensions such as Fishpig’s Smush It extension are around 10% more effective.

Magento 2.x adds ImageMagick for image processing (Stores > Configuration > Advanced / Develop > Image Processing Settings) but this appears to be more about efficiency – ImageMagick is able to process images slightly more efficiently (in terms of time).

Magento 2.x will have to solve this issue, at least initially, through the use of an image compression process.

Picture Element

Another method of image size optimisation is to reduce image sizes for smaller screens. In traditional responsive design, a larger image is simply resized by the browser, the same full-size image will still be downloaded, and in some cases, a full size (1200+px) image will be downloaded and hidden using @media rules.

Lots of “better” solutions exist for this, but our preference is the <picture> tag:

<picture>
 <source srcset="mdn-logo-wide.png" media="(min-width: 600px)">
 <img src="mdn-logo-narrow.png" alt="MDN">
</picture>

See the documentation on Mozilla.org.

Where supported, the <picture> tag allows users to download an image that has been optimised for 320px, 720px, or whatever size is appropriate. Where not supported, the default image will simply be used.

WordPress developers will note that this has been core WP functionality since version 4.4. WordPress’s ability to resize thumbnails allows this to be done practically automatically.

This is not a Magento 2 “issue”, but it is absent from the Luma (default) theme supplied with Magento 2. This is a shame because Magento’s position as a leading eCommerce platform could have really aided its adoption and helped to speed up the web. Front end devs will need to implement this themselves.

Webfonts

It is also worth mentioning that the default Magento 2 theme uses a custom webfont for icons and it is good to see Magento pushing this. Adoption of services such as IcoMoon should definitely be encouraged.

Prerendering

There are several ways you can implement pre-rendering for a JavaScript-heavy website in Magento, and extensions can be some of the quickest and cost-effective ways to do so.

PluginArchive offers a good pretender option, as does MageCloud, both of which are useful options.

Minor Issues

HTML Sitemap

HTML sitemaps are useful, especially added to 404 pages because they give users a reasonable method of finding a new page. This was a core feature in Magento 1.9.x – you usually would have seen it linked from the site footer – e.g. http://www.made.com/sitemap/ – with product sitemaps also being available.

It had some small SEO benefits too.

  • More internal links!
  • They were an easy way of crawling multiple pages or getting abstract categories indexed (categories that fall outside of the normal hierarchy) e.g. “Back to school essentials”, “Romantic gift ideas”.

This feature has actually been removed from Magento 2.x; you will have to implement this yourself via a custom template.

Google Shopping Feed

This one is purely SEM (Search Engine Marketing), not SEO. A Google Shopping feed is essential for a modern eCommerce site.

A shopping feed gives Google an up-to-date image, price, product name for product listing adverts (PLAs) and dynamic product remarketing.

Not to get confused:

    • Product listing adverts – paid adverts that appear when specific product names are bid on.
    • Remarketing – targeted advertising on Google Display Network (banners) or Google Search at people who have previously interacted with your website in a way that suggests they are likely to purchase. For example, starting an order with over £100 in their shopping basket but not completing the order.

This involves supplying Google with an XML feed with key product attributes (for clothing, it includes age group, colour, gender, size) and then set up rules to drop a remarketing cookie or by building an audience through another method.

We are not going to talk about the methodology for configuring your website to drop a cookie or building these audiences for remarketing / product listing adverts, because the method for doing this is not specific to Magento.

Implementing a product feed in Magento 2 requires the use of a third-party plugin. PushON currently recommends Wyomind’s Simple Google Shopping extension for Magento 2 because we found their Magento 1.9.x version simple to set up and use.

Keep reading to discover more about Magento 2’s Google Analytics Setup.