AMA Technical SEO Meetup with Martin Splitt in Toronto – Recap

Last week I organized a meetup with Martin Splitt from Google. The meetup took place in the Toronto Google office. I’m so grateful to Martin! He’s a wonderful person who is always eager to share his knowledge, answer your questions and even show some magic tricks with cards!

Also, thanks to everyone for coming! There were people from different backgrounds: from marketing, sales, development and of course SEO.

In this recap post, I’ll share many useful things:

• Answers about PWAs and AMPs, schema markup and more
• Googlebot and JavaScript: how things can go wrong
• Tips on communication between developers and SEOs
• 2 insights
• 1 interesting fact about Martin
• A video on Angular SEO

Let’s go!

Q1: The How-to structured data help says that this type of schema markup can’t be used for advertising purposes. But what does ‘advertising purposes’ mean specifically?

Advertising means when, let’s say, you write how to tie a tie and then what you are trying to publish in the structured data is like ‘You never have to tie a tie with Snap-On Tie ™’. That’s a very blatant case of advertisement in structured data.

How-to markup should be more generic and as vendor-agnostic as possible. Or if you make the how-to specifically about a specific product, I think that is also fine because if I’m checking how to fix my Mercedes and then Mercedes has a specific way of doing that, that’s also OK. What is not okay is basically using it as a channel to push for your specific product. 

Q2: Fewer people are talking about PWAs now. Is it still worth making them?

It’s probably nobody talking about it because it’s kind of like old news. So the fact that it’s not being talked about is a very bad indicator if you should do it or not. 

No one outside of this specific PHP events is talking about PHP anymore. Does that mean that you shouldn’t use PHP anymore? Well, it depends, it’s a tool. If a tool solves the problem that you are having then it’s a great tool. If it doesn’t and you’re still using it, then it’s probably not a good tool.

PWAs have matured a lot so I would highly recommend looking into that topic because it’s a great way of providing a progressive web app – that’s what PWA stands for. 

Progressive web apps are a fantastic way of providing good user experience to your users. So a progressive web app is basically when you have a website and then you enhance it with things like HTTPS so that the transfer between you and the server is encrypted so that no one can tamper with data and in flight. That’s the very first step. Then you make it fast so that it responds quickly, it is loading on mobile connections quickly; make it mobile friendly so that it displays on every device including phones. 

You can add a file that describes the progressive web app like ‘this is the icon’, ‘this is the image’. And if you do that then Chrome or actually all browsers might offer you a little pop up if you go to that PWA website more often, it might go: ‘Do you want to add this to your home screen?’. If you say ‘Yes!’, then you’ll have a little home screen icon on your phone and it behaves exactly like an application. You can switch between the apps and PWA will show up just like an app so you can install the web application for the websites.

For that to work, you also need one more thing, it’s called a service worker. It’s a piece of JavaScript that allows you to control how data is fetched from the network and how it’s cached and stored on the device in order to make it offline available. How you do that is up to you: it’s basically just like: this is your web application, this is the internet and the service worker is a program that runs right in the middle. It gets called when the website is trying to load something from the network: anything like an image, HTML, CSS file or JavaScript files, any API calls – it all goes to the service worker and then you can decide what you want to do. 

And then there are different approaches to it. One approach is to say: we load always from the network first and only if that fails then we take it from the cache. Or maybe you just show some offline page when it’s offline and it makes no sense to have something else.

So yeah, definitely if you have that and you qualify for Progressive web app and basically just means that your website will be fast, secure, offline-capable and just a good experience on mobile and as well as on desktop. I highly recommend doing it because it just shows us that you have so much higher interaction and engagement from users. We have a bunch of case studies. I think if I remember correctly when Starbucks launched their PWA, they had an increase in conversions and in business and engagements with users. Flipkart in India is a huge retailer that has seen huge boosts over the native app. They [PWAs] are also a lot smaller, right? Last time I installed Pokemon Go with like a hundred megabytes or something like that. And then even the small application, I needed an AR measure tape app from Google and that was like 20 megabytes! A web app is normally like a hundred kilobytes or something like that. So just saves the users space on their smartphones as well. 

AMPs – accelerated mobile pages –  are basically a subset of HTML that is optimized to be relatively fast or like load very fast and pretty much instantaneously. And when we discover that then what we as Google do is we cache it on our Google infrastructure so that we make sure that we distribute your website in caches around the world and users get the closest cache, so the website loads really really fast. I highly recommend that for publishers. If you are a publisher who is basically a newspaper or a magazine or a TV company, if you have edited content or like proper copywriting content for readers to consume, AMP is a really good way to make sure that it looks fast and has good experience for the user. Outside of publishers, I haven’t seen that many benefits from it [using AMPs].

AMP has nothing to do with ranking. Some people think that AMP does mean ranking benefits but it doesn’t. If you look for instance, for the New York Times, then you will sometimes find that some articles are ranked higher than the AMP version of it.

With that being said, AMP has its benefits because AMP means processing HTML on the Google server side and then producing a really optimized version of it so you don’t have to, which is great. It also means that you have AMP ads, a way to have advertising working fast on your website, even on mobile, which is something really hard to do yourself. So if your revenue system is ads based, then AMP is definitely worth it. 

AMP and PWA are independent concepts. You can have AMP PWA, or you can just have PWA or you can just have an AMP page. 

I personally think it depends on what you’re doing if PWA or AMP is the right answer. For example, for forums PWA makes sense. If there’s a specific thread that I’m subscribed to, it would be nice to be able to access this information even if I’m offline and to have that load because you can, as I said, in your service worker, choose what you do. So what you can do is what’s called a cache first approach: whenever I load the page, it goes straight to the cache and gives me the results back which means it loads instantly because it’s coming from the device. And then in the background, you’re updating the cache from the network. And then if that fails, then it fails, or if that works out fine, then you get new content in the cache. And the next time I refresh I get the new content.  

Q3: Some time ago it wasn’t recommended to inject schema markup using Google Tag Manager. But are things better now after the Evergreen Googlebot has been introduced?

Yes, it’s better now.

I would highly recommend not relying on JavaScript in the browser to do the right thing necessarily. Generally speaking, it’s a good thing but it’s less robust than having it in the initial HTML. So for robustness sake, I’d recommend against it, but in general, it is perfectly fine to use it. 

Before, using Google Tag Manager to add important information [like schema] was advised against. But now with the new Googlebot using Google Tag Manager is no longer advised against. 

Q4: When you add 3rd party reviews to your website, can Google parse them properly or you need to do something specific to make sure Google sees the reviews?

I would be very careful testing that because it is the third party script so it might fail, it might have weird problems and you can’t control that. If it renders properly in the DOM and it shows up in the rendered HTML, it’s fine. 

If they [3rd party scripts] give us 500 or 400 errors, we can’t fetch their stuff. And if we can’t fetch JavaScript, we can’t work. That does happen sometimes. That would be my biggest worry that for some reason we can’t access the external resource. Or if they get their robots wrong. Robots.txt is interesting one sometimes: if the 3rd party blocks Google, it can’t access the resources. I’m not saying that that’s going to happen. What I’m saying is just this is a possibility that is outside of your control. 

Q4: Is there anything like ‘render budget’?

There’s no render budget. Oh, it takes a minute or it takes 2 – it’s not just like that. Try to be as fast as possible and as reasonable as possible because we are not gonna wait for every website Infinity to finish loading. We have certain heuristics, we have certain techniques to figure out when the website is loading or when it’s exceeding a reasonable timeframe. But basically, if it works for the user, it will very likely work for us timewise.

Q5: How do developers and SEOs can interact in the most efficient way? 

I believe that as a developer you usually look for certain things. Usually developers test the systems they build, and one of the things is that a lot of SEO is really hard to test automatically. So like as you’ll try to automate as much as possible, but can’t automate everything, there are things that you just can’t automatically test properly. So they usually watch whatever they can in terms of automatic test environments, but they still need someone to keep an eye on both the production environments like the website that is outside of their sphere, and then also take a look at what might happen when they deploy the next version.

How that collaboration looks like depends a lot on the organization. If you have a scrum team that is a cross-functional team, then it would be cool to have one SEO personally or a few SEO people on the specific scrum team so that the developer can sit down with them and say: ‘So I implemented this feature, but I have the following challenge, or I have the following issue. I need this page to not be indexed by Google. How do I do this?’. And then the expertise from the SEO comes in and the SEO can give their expertise right away. 

Or if the SEO finds a problem and they can pair with the developer and talk through it. And I cannot foresee developers reasonably prioritizing issues in terms of SEO. Development, technical issues – yes, you can prioritize them: simple quarters: simple to do high-impact; hard to do high-impact – you gonna look at these. And then there are simple to do low-impact; high risk or high amount of work and low-impact. So basically this is an easy prioritization but for SEO issues it might not be obvious for them how to prioritize. It takes experience. And to be honest, even SEOs get it wrong sometimes. ‘Oh my God, we need to fix all 404s in Search Console!’. No, just because someone is linking to the page which doesn’t exist, it doesn’t mean that you need to fix that. You need to fix things if you have important pages which are not getting indexed or if you have pages that are indexed that shouldn’t be getting indexed – those are the things that you need to be looking at. And this judgement I would leave to SEOs and I would like them to pass on and prioritize the list of stuff to developers. 

As I said, it can work both ways: SEOs giving input to developers and developers giving input to SEOs. Both of that works I think. But that’s just my opinion, everyone’s opinion on this table is as valid. 

How would you like to work with developers as an SEO expert? 

(This was a question to yours truly, so here comes my answer)

Me: Closely. Yeah, I have experience working with developers and in many cases, there’s a lot of misunderstanding. But what I found out from an SEO perspective: for an SEO, it’s always great to give a clear understanding of what you’re looking to achieve and acceptance criteria of what you want the outcome to be. Yeah, and be friends, be nice to each other. Don’t push things that don’t need to be pushed right now just for the sake of fixing things. But concentrate on those things which are more important right now. 

---

These were the answers to the most interesting questions. And now I’m going to share a few insights!

Insight 1: Structured Data Testing Tool vs Rich Results Tool

It’s better to use the Rich Results Test tool instead of the Structured Data Testing tool.

‘The thing is that the Structured Data Testing tool is not as accurate as the Rich Results Test. It does help you see if you have any errors but the Rich Results test gives you more useful information because it uses the actual pipeline that Google shows to potentially show rich results.’ 

Insight 2: Not all mobile-friendly alerts in Google Search console are equal

Sometimes you get an alert saying that your page is not mobile-friendly. But when you check it in the Mobile-Friendly tool, the page IS ‘mobile-friendly’.

This may happen if Google couldn’t load CSS, for example, and without it, your page doesn’t really look good on mobile devices (e.g. elements are too close). Then GSC will send you a notification. But when Googlebot revisits the page and loads CSS, everything is OK.  This happens sometimes, and there’s nothing to worry about as long as the affected pages successfully pass the test in the Mobile-Friendly Tool. 

The Interesting Thing About Martin

Well, there are many! But I’ll share this one 🙂

Martin has a Google alert on his name because. ‘It’s quite interesting to see what has been written from the things I say’.

Guess what? This post will be delivered to your inbox, Martin 🙂

Bonus: Angular SEO Demystified

Right after our meetup, there was a developer meetup in Google, and Martin was invited to speak there about Angular and how to make sure it’s properly optimized. Check out this video, lots of good stuff there (I especially enjoyed the part about a toaster!).

… and more photos!

What’s next?

Firstly, if you have anything to say about the Developers Google Help, don’t hesitate to use the ‘Send Feedback’ option:

Secondly, you can learn more about how Google works as well as how to properly optimize your website by reading my Google Webmaster Hangouts Notes.

Also, make sure to subscribe for the blog to have valuable SEO tips delivered directly to your inbox!

---