This Chapter – Magento 2.0: Advanced SEO Fixes

The Guide


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

Please note that this chapter doesn’t cover every outstanding issue with your Magento website.

  • Many of the SEO issues with your site will relate to how it’s used – or indeed, misused. Many of these issues are common to other ecommerce platforms so will not be discussed.
  • This chapter focuses on fixes that need some development or commercial extensions to implement in Magento 2.0.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 (filtered categories) is one of the most common sources of issues with ecommerce websites. Unfortunately, Magento 2.0.x is no different. If you are interested in why this is an issue, click below for an explanation.


Faceted navigation is a challenge on ecommerce sites because it creates endlessly crawlable sites. Looking at a Magento 2.0.x category page;


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

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

Why is this a problem?

Google have never explained why this is an issue directly but consider 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.

Crawl Budgets

Consequently, each website has a “crawl budget”.

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

Crawlability as a ranking factor?

Combine the above reasoning.

SEOs have theorised that Google may favour freshness as a factor for ecommerce – if Google are 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 unsatisifed with the results that Google have given them – especially if your site’s response to discontinued or out of stock products is a 404 page.

To summarise the above in one paragraph – 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.

Solving this problem

In the previous chapter, canonical tags were setup on the category page – this PARTIALLY helps solve another aspect of the issue faceted navigation causes but doesn’t prevent Google from still needing to crawl these pages.

Google have 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 do or have 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 


 into something like 


 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 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.

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 amount 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. 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).


This approach is discouraged because of the sheer amount of thin or high duplicate (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 noindexing or using canonical tags to ensure that combinations of filter that don’t 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.

Nofollowing at the link level means changing the HTML in a link from something like;

<a href=”>Chocolate</a>
&lt;a <strong>rel=”nofollow”</strong> href=”;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

app / design /frontend / {your template} / template / catalog / layer

to add a nofollow tag.

Magento 2.0.x Nofollow

In Magento 2.0.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.0.x pages that do not need to be crawled include;

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

All links to these pages can be safely nofollowed.

The above situation is identical in Magento 1.9x, although links to the following page types also benefitted from nofollowing.

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

This is unnecessary in Magento 2.0.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 – they should not be nofollowed.

May 2016 Update

In May 2016, a Google Hangout with Google’s Gary Illyes indirectly contradicted some of the recommendations from the 2014 Google Webmasters Blog. Nofollowing 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 doesn’t 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 individual 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 setup just to increase the amount 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 was 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 wasn’t really targeted at ecommerce sites – more content and information sites – but they will have been caught in the cross-fire.

Is this still a problem?

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

In fact, Google have confirmed this publically. So!

  • 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.

Websites built on any CMS create thousands of extra pages as a convenience factor – if Google were to penalise every site for doing this, nearly every site would suffer.

One retailer PushON looked at had approximately 2.5 million pages indexed. They had 1600 products – and ranked well for “head terms”.

So it’s not a problem anymore?

Unfortunately, this relies on Google’s algorithms to understand that any duplicate/thin content on your site isn’t manipulative. This isn’t 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.

To summarise

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 also creates duplicate content. E.g.

The basic SEO setup added special tags to the Magento category pages – to ensure that these filter pages are “canonicalised” to the category page that created them – a tag is inserted that indicates to Google that this page is merely a duplicate of the “proper” 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.

Signals vs Directives

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

Fixing Duplicate/Thin Content

  • A common fix is to block any URLs with a query string in the robots.txt – unfortunately, this doesn’t remove pages that are already indexed – so isn’t 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.

Noindexing in Magento 1.9.x


Creare actually have 2 ways of doing this in Magento 1.9.x.

Noindexing in Magento 2.0.x

There’s 2 commercial options for fixing this in Magento 2.0.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 (Enterprise).

Noindexing Search Pages

Every time a user performs a unique search on your site a new URL is generated (e.g. If not managed correctly, search engines can find and index these URLs which can cause numerous issues. It’s 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 indexing these pages is a mistake.

  • These pages will often be thin or duplicate content.
  • Search pages will include the searched keyword in the page title and heading as though they were optimised for this keyword. This can compete with categories or product pages that are better suited for this keyword (cannibilisation).
  • It allows junk pages to be created remotely – for example, users or competitors could get abusive pages indexed 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.
hypothetical example of how this might be abused

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, just improve your navigation to ensure that users use the menu instead of internal search.


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’s a handy blog post on this subject.

Pagination Code

This involves adding mark-up like

<link rel="prev" href="" />
<link rel="next" href="" />

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 can also be fixed using plugins.

Magento 1.x Pagination

Magento 2.0x Pagination

Similar modification should be possible in Magento 2.0x, however, several commercial extensions are available already which implement this.

  • The Mageworx SEO Suite Extension (described above) also adds this. A competing extension from Mirasvit is also available but we are unable to recommend this without testing it 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 (install extensions/modify the site), a good short term solution for both pagination and attributes can be provided via Google Search Console – Crawl > URL Parameters


And configuring the p parameter like the image below.


Other parameters that can be updated in Search Console.

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

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

Canonical Tags

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

Canonical on CMS pages

Whilst CMS pages have been substantially improved in Magento 2.0.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);


Canonical on CMS Pages in Magento 1.x

In Magento 1.9x, this was easily fixable using an extension (Creare SEO) or by adding;

 <reference name="head">
  <action method="addLinkRel">

to the page layout, revising the URL to reflect the page you desired to be the canonical URL for that page.

Canonical on CMS Pages in Magento 2.0.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 manually override canonical URLs on products and categories.

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


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">
  <action method="addLinkRel" translate="title">

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.0.x Canonical Overrides

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

Alternatively, this can 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 very 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 setup for English speakers in Australia, UK, Canada and USA, Hreflang helps tell 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 specific 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, specifiying 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.


Hreflang in Magento 1.9.x

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

Configuration &gt; General &gt; Countries Options



As well as language (same page,

Locale Options



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.0.x

  • Similar development and similar methods will work to ensure that each storefront can be associated with a language via1
    Store &gt; Configuration &gt; General / General &gt; Country Options(and1
    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’re implementing international sites via Magento, it might be tempting to implement geo-based IP redirects – for example, redirecting from and to 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’re in a different country to the one intended. As long as their preference is remembered via a cookie, this is unobtrusive. 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 don’t 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.


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 will be quite outdated 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.
  • Your sub-category pages become almost like a homepage in a site. Sell more types of felt tip pens? More internal links.

So the SEO benefits of breadcrumbs are simply this. Breadcrumbs can let you autopilot 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’re on more effectively – but most sites won’t need this level of micromanagement.

Doesn’t Magento have breadcrumbs?

Unfortunately breadcrumbs don’t work like this in Magento 1.9.x or Magento 2.0.

  • 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.0 will be stripped. E.g.
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.


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 just from the category page.

With Magento 2.0 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 product that strips the URL to the root and non-working breadcrumbs.

Mostly people go for the latter.

The Solution

We’ve 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 doesn’t scale well.

  • In Magento 1.9x, there’s 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 hasn’t yet been ported over to Magento 2.0.x – but this should be available from June 2016 onwards.


Schema (“structured data”) is one of the more welcome additions to Magento 2 – it’s discussed in the “What’s new” section – provided developers properly extend this functionality. Unfortunately, there’s 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="">
<span itemprop="priceCurrency" content="USD">$</span>
<span itemprop="price" content="1000.00">1,000.00</span>
<link itemprop="availability" href="" />In stock

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="" />

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


  • In Magento 1.9.x, there’s several free Schema solutions – these tend to use JSON+LD so they’re very easy to implement into your site. Creare’s extension does this out of the box.
  • For Magento 2.0.x, developers will need to shift the declaration of the Offer Schema into a containing div that encompasses both.

Product Schema

Product Schema isn’t 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 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 proven – however, click through rates from search may be improved as users are able to 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.

  • Lossless compression tools such as jpegoptim or PngOptimizer are able to 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 properly optimised.
  • Google’s own lossless compression tool isn’t available as an API (as yet) but it’s 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.


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

  • Solutions for this tended to be server based – usually a CRON job that compressed the images. If scheduled appropriately, this rarely put too much stress on the server.
  • Extensions such as Fishpig’s Smush It extension are around 10% more effective – but are not currently available for Magento 2.0.x.
  • Magento 2.0.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.0.x will have to solve this issue – at least initially – through use of an image compression process.

Picture Element

Another 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.

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

See the documentation on

  • 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 auto-piloted.

This isn’t really a Magento 2 “issue” but 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.


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

Minor Issues

HTML Sitemap

HTML sitemaps are kind of 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’ll usually have seen it linked from the site footer – e.g. – 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.0.x – you’ll have to implement this yourself via a custom template.

Google Shopping Feed

This one is purely SEM, 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.

  • 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 setting up rules to drop a remarketing cookie or by building an audience through another method.

We’re 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 methodology for doing this isn’t specific to Magento – tweet @PushONltd if you’d like to read a blog about this.

Implementing a product feed in Magento 2 requires use of a third party plugin too. PushON currently recommend wyomind’s Simple Google Shopping extension for Magento 2 because we found their Magento 1.9.x version simple to setup and use.