Talk to Franz

Chapter 8 of 8 · Part II

Other Things To Think About

We’ve almost covered everything you need to know about SEO - soon it will be up to you to execute all the things we have discussed in this book. But before that, there are a few other (but very important!) things you must know.

Mobile

Go responsive. Everything else is insanity. If you want to be convinced that mobile is important, then this is the wrong book and the wrong year. Mobile is a fact. The majority of all search demand for any vertical (including all B2B) is via mobile devices. There are three acceptable ways to communicate that you are a mobile ready site to Google. These are:

  • responsive design
  • user agent specific serving (one URL, two-page version)
  • mobile redirect (two-page versions, two URLs, m. (m-dot)domains)

The big challenge when it comes to mobile sites is that the medium that was used to create the website, so that big, fat, powerful desktop computer or that fancy Macbook, is no longer the medium that the majority of users are using to consume it. That’s why it’s imperative that during the design process, mobile users are prioritized and tested accordingly.

Any logic that attempts to create two completely different page versions (mobile and desktop) leads to underdeveloped, less maintained and often broken mobile sites. Adopting a responsive design across your whole webproperty mitigates this issue.

If you wish to learn more about mobile SEO setup, then you will find everything you need to know in the Google spec [smartphone optimized sites google].

In 2016, Google announced, that they will, in the near future, render (see) the pages they index in the mobile view, and the desktop view will be just as an alternate view. Currently, as of the writing of this book in 2017, it is still the other way round. The details of how Google will deal with this major change can only be seen after they have actually switched to “mobile first indexing.” Until then, relax, go responsive.

Render As Googlebot And Other Tools

Since 2014, you no longer have to guess how Google sees your site. That’s because, in Google Search Console, you can choose to render web pages for Googlebot (Desktop) and Googlebot-Mobile.

The Fetch as Google tool in the old Search Console

Use this tool like crazy. This is how Google sees your site, and these are the views you are optimizing for. This is also the view we are using to determine the “fold,” so the content that is visible without scrolling. If Google cannot render sensemaking, good looking screenshots with this tool, then your site is broken and needs to be fixed. Now.

Additionally, Google offers a “mobile-friendly test tool.” Take this test and if you fail, follow the instructions to fix your site. There is also Page Speed Insights that tells you how to make your mobile site fast. Use these tools to fix these issues, too.

App Indexing

App indexing is a technology that allows Google search results to point directly to content within native Android or iPhone apps. The challenge when it comes to App Indexing is that URLs are an alien concept to apps, and Google needs something to point to. So basically you have to twist your app to fit into the page paradigm.

You can find the spec at [Google Firebase App Indexing]. It’s a horrible spec. App indexing has lost momentum in the years since it was introduced, with the overall traffic impact being less than overwhelming. So speak with your trusted native app developer if app indexing is a choice for you. They will most likely say no. Trust them.

AMP - Accelerated Mobile Pages

Accelerated Mobile Pages is an initiative by Google to produce fast (they call it “instant”) page loads on mobile. It’s a subset but at the same time an extension of HTML that can be pre-cached and pre-rendered by Google. This means, that when traffic is sent to an ‘amp’ed page, the user stays within Google (but traffic in GSC and GA is counted towards the webproperty).

It’s all in the name of Google providing a fast user experience to its users, wherever they go. It’s a move away from responsive design (one HTML for all browsers, clients, and users) to a separate version of mobile users coming via Google.

Google is also promoting AMP HTML as a way to become more deeply integrated into the Google mobile experience. Currently, news and recipe verticals are seeing a positive impact on their traffic because they are well integrated into the Google mobile experience.

The downside for businesses with AMP is you need to maintain (create, test, manage, quality assurance, and so on) yet another version of your pages, and you are limited in what you can do (with Javascript and HTML) within an AMP page.

From a technical point of view, you have to direct from your “normal” page a rel=“amphtml”, so for example, <link rel="amphtml" href="https://www.example.com/a/slug/amp">, to the AMP HTML page. The AMP HTML page must point a canonical back to the “normal” page. The AMP HTML page must be according to the AMP HTML spec, and be validated correctly according to this spec. Also, there are some error reports available in Google Search Console about AMP.

My current standing on this topic is just to have a proper, working, unbelievably fast, long term optimizable, responsive website, and not do AMP. This recommendation might change significantly in the future depending on how the marketplace (a.k.a. Google) develops.

On the other hand, if you just do not manage to create a fast website, then do AMP. That’s what it is designed for: to force publishers to have fast web pages in a way that they can not screw it up.

Multiple Domains And Languages

Another important decision for growing webproperties is to how to deal with different markets and languages. My recommendations on this topic vary from company to company, and your specific business goals. However, here are some basic thoughts:

Always start with a single domain! From the sheer amount of guidance in this book, you will have realized that it’s hard to have one well search engine optimized webproperty. You need to optimize the platform and the processes. Therefore, to keep things as simple as possible when you start to go multilanguage, use rel=alternate links on all pages with different language versions.

<link rel="canonical" href="http://www.example.com/en/seo" />
<link rel="alternate" hreflang="en" href="http://www.example.com/en/seo" />
<link rel="alternate" hreflang="de" href="http://www.example.com/de/seo" />
<link rel="alternate" hreflang="es" href="http://www.example.com/es/seo" />
<link rel="alternate" hreflang="fr" href="http://www.example.com/fr/seo" />
<link rel="alternate" hreflang="it" href="http://www.example.com/it/seo" />

Important note: Every targeted page must still be language consistent; the boilerplate (for example, the navigation) and main content must be the same language. Otherwise, the site will not perform. You must always make sure that the “new” languages have language namespaces (/en/, /de/, /es/ and so on). Language namespaces are not important for Google (language is determined on a page per page basis), but majorly important also for the manageability and measurability of the site:

  • https://www.example.com/en/a/understanding-seo
  • https://www.example.com/de/a/seo-verstehen

Make sure you submit different sitemaps for the different language versions.

The benefit of the single domain approach is that you still have only one webproperty to care about (meaning only one webproperty that you must make sure receives more and more inlinks over time). I have seen this approach work well for small sites, with up to a combined total of about 100,000 web pages (including multiple languages).

Note: If you go multilanguage, single domain, it’s best practice to put all languages in a language namespace. This is true for all but the startpage. The startpage must always be in the root. For the startpage, implement a logic like this where one language owns the root startpage:

<link rel="canonical" href="http://www.example.com/" />
<link rel="alternate" hreflang="en" href="http://www.example.com/" />
<link rel="alternate" hreflang="de" href="http://www.example.com/de" />
<link rel="alternate" hreflang="es" href="http://www.example.com/es" />
<link rel="alternate" hreflang="fr" href="http://www.example.com/fr" />
<link rel="alternate" hreflang="it" href="http://www.example.com/it" />

In this example, all other /en/ pages will be within the /en/ namespace. The startpage is the (annoying) exception, as you open yourself up to a whole area of SEO phenomenons if there is no startpage in the root of the domain.

Going Multidomain!

As soon as you are targeting different markets and languages or becoming bigger (and have more than 100,000 pages), I recommend that you go either multidomain or multi-subdomain. Adopting multiple domains allows the use of recognizable local extensions, for example, .co.uk in the UK or .de in Germany. In the case of going multidomain or multi-subdomain, use rel=alternate for market targeting over the pages of the different domains.

Multidomain

<link rel="canonical" href="http://www.example.com/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />
<link rel="alternate" hreflang="en-gb" href="https://www.example.co.uk/" />
<link rel="alternate" hreflang="en-us" href="https://www.example.com/" />
<link rel="alternate" hreflang="de" href="https://www.example.de/" />

Multi-subdomain

<link rel="canonical" href="http://www.example.com/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />
<link rel="alternate" hreflang="en-us" href="https://www.example.com/" />
<link rel="alternate" hreflang="en-gb" href="https://uk.example.com/" />
<link rel="alternate" hreflang="de" href="https://de.example.com/" />

That said, having a multimarket or multilanguage site is hard. Not only twice as hard, but complexity and effort squared. As soon as you go multilanguage or multimarket, the versions of the website begin to diverge. It’s a whole new layer of complexity to manage. But although you have more work, you will also have more manageability with multiple domains. Attempting to do all this on one domain for a growing website is project suicide.

My conclusion on this topic is that overall, it depends. Rel=alternate is your friend. Check the Google spec and test via Google Search Console to see if your targeting strategy is working correctly.

SEO Success

If you’ve made it through the book, congratulations. Now you know: there is no secret to SEO. It is not a mystery or a trick, nor can it be download or sourced out to SEO agencies that don’t touch your site or your business.

SEO is solved. I have told you what you need to do, and why you need to do it, and hopefully put myself out of a job in doing so. All you need to do is apply it to your business.

Remember, SEO is the business of getting found, and SEO is a choice. Choose wisely; the success is up to you!

Rather pay than subscribe? The ebook is on Gumroad and on Kindle. All chapters.