Mobile Ranking Factors and How to Be Number One with Cindy Krum

In this Episode

• [00:49] – Cindy talks about the main things that you need to be cognizant of in mobile marketing.
• [01:41] – What does mobile-first indexing for Google mean for marketers?
• [02:48] – Cindy explains what responsive design is, and explains both its upsides and a downside involving bounce rate. She and Stephan then discuss this.
• [05:19] – While Google is okay with other options, responsive design is their favorite.
• [06:19] – Cindy has written a couple articles on her predictions on what mobile-first indexing will mean for the SEO community. She then backs up and explains that right now, there isn’t a great term for all the stuff that’s getting internet enabled, and that many things are getting lumped in the “mobile” category. This is why she thinks that “mobile-first” is a misnomer.
• [09:32] – Stephan points out that listeners should note that search engines can follow a train of thought.
• [10:17] – Cindy thinks Google is having a brand identity issue.
• [11:56] – Cindy explains what the relevance of everything she’s been saying to a mobile marketer is. She then explains that AMP is an interesting side note, but she’s talking more about Firebase.
• [14:02] – Stephan pulls us back a bit, offering some insight and explanations about Schema, JSON-LD, metadata, microdata, and more.
• [16:39] – Cindy never expected Stephan to be her “nerd interpreter,” she jokes. He mentions his other podcast, the Get Yourself Optimized.
• [18:05] – What is AMP, and why do we need to take action on that immediately?
• [20:01] – Stephan chimes in, explaining other aspects of AMP and responsive design. Cindy continues by talking about another restriction, which is that you’re strongly encouraged to host all of your external content in Google’s cloud hosting. She then emphasizes the importance of engagement.
• [23:37] – Stephan explains that AMP pages are hosted on Google and also link to Google. Cindy elaborates on this.
• [25:53] – We go back a bit, with Stephan discussing some actions to take now that we’ve discussed AMP in depth.
• [26:36] – Cindy talks about moving to responsive design.
• [28:22] – Stephan talks about the difference between dynamic serving and responsive design. Cindy then explains that dynamic serving is tougher to test and tougher for Google to crawl.
• [31:54] – Stephan brings up app indexing, which he and Cindy discuss using the example of Yelp.
• [34:14] – We circle back to a particular point about dynamic serving: having the vary header set in your HTTP headers.
• [35:48] – Cindy explains what JSON-LD is, and what marketers should know about it from a mobile marketing standpoint.
• [38:17] – We learn what an API is.
• [39:06] – Cindy differentiates regular mobile apps from progressive web apps.
• [41:50] – Stephan offers an old-school equivalent to what Cindy has been saying about progressive web apps.
• [42:52] – One of the things that slows things down the most when on web pages on the phone, every page has to reload even though much of the content is the same. This is different with PWAs, Cindy explains.
• [43:53] – What is Firebase in relation to PWAs? Through her answers, Cindy makes clear that she thinks having a PWA is a better choice than making native apps.
• [46:34] – There are ways to use AMP HTML in your PWA to make it very fast. She and Stephan then discuss the fact that a handful of apps are throwing off stats for apps in general.
• [48:48] – We learn more about what’s important in terms of ranking in the app stores.
• [50:29] – Stephan launches into a lightning round of quick questions. Should people check to see what their mobile page speed is?
• [53:14] – What is deep linking?
• [55:31] – Listeners can email Cindy at [email protected].

—

Transcript

Hello and welcome to Marketing Speak. I’m your host, Stephan Spencer. Today, we have Cindy Krum with us. Cindy is the author of Mobile Marketing: Finding Your Customers No Matter Where They Are, as well as CEO and founder of the mobile marketing consultancy, MobileMoxie. Cindy, thanks for joining us today.

Thanks for having me.

Let’s talk about Mobile Marketing and Mobile SEO in particular. What are the main things that you need to be cognizant of and why?

Mobile is changing really quickly. With SEO, there’s all the stuff with the digital assistance coming into play now, those are particularly scary because there’s only one correct result. If you don’t rank number one, you’re not in the mix at all. That’s pretty hard for SEOs to deal with, the concept of not even having the choice of 5 or 10 or whatever. There are apps in the mix and mobile-first indexing, it’s all just up in the air.

Let’s start one at a time here. Let’s start with mobile-first indexing because that was announced late last year at Pubcon by Google, by their  placement, Mr. [00:01:34], if I pronounced that correctly. What does that mean for online marketers, mobile-first indexing with Google?

They haven’t elaborated very much except to say that webmasters need to make sure that their mobile renderings of their pages have all of the same content and SEO signals as desktop. That could be a lot of work for some, could be no work at all for others. The most important thing that they’re focusing on is schema. For companies that have a responsive design, this should be fun, or mostly fun. For companies that are doing dynamic serving or that still have m. websites, it could be harder.

Let’s assume that the listener does not know what dynamic serving is, schema, all the stuff that we have talked about in the last minute here so let’s unpack this a bit. Responsive design, let’s define that. I presume that many of our listeners will know what that is but not all. What is responsive design and what’s the difference between that and dynamic service versus m. separate mobile website or mobile DOT or even a .mobi if they’re still out there?

Responsive design is a website that uses one set of URLs to handle desktop, mobile, and tablet. What it does is it takes the content and rather than squishing it down to postage stamp size or letting it bleed off the side of the screen, it rearranges it in the most palatable way possible. For instance, if on desktop it’s three columns but those columns just don’t work well on mobile phones, they’re too wide or something like that, it might stack the columns or just move things around. It modularizes the site. Developers can plan and understand and then decide for themselves how they want the pages to be rearranged on the different renderings but it’s the easiest, from an SEO perspective, because you get to use the existing signals on the desktop site. The downside that’s really, really talked about is that, if the designers and developers make bad decisions for the mobile rendering, you’re pushing the bounce rate of the entire site down so you don’t get to segment off mobile and say, “We don’t care about mobile because it’s not a lot of our traffic.” Well, if it’s any of your traffic, if it’s 25% and 90% of that 25% is bouncing, that could be a problem that affects your whole site then.

That would affect your Google rankings because although bounce rate is not being watched by Google necessarily, dwell time is, which is all about looking at who’s clicking on which search results and whether they are hitting the back button and going back to search results and clicking on another listing because the user didn’t like your website in the search results and left and went to something else. That dwell time is being monitored by Google. If you have terrible dwell time because you haven’t created something that’s particularly usable for mobile users, that’s what the issue or let’s say 90% bounce on mobile and that might be 25% of your traffic and that’s going to set a bad precedent and get you potentially lower rankings in Google.

Absolutely.

Now you’ve got dynamic serving as an alternative responsive design. Responsive design, just to be very clear, is the preferred approach according to Google.

Yes. They’re okay with other options but from their perspective, their internal reports show that there are fewer errors when they’re crawling responsive design, they have fewer instances where content just can’t get indexed so they say it’s best for webmasters and companies just because the other options are much more error prone.

Actually Cognizant, we’re getting really geeky, really faster. Let’s come back and talk about dynamic serving in just a minute. Let’s differentiate digital assistant type of searches from mobile searches that you type in with your fingers or thumbs or whatever because you will get multiple results with those kinds of searches but when you’re talking to your phone with a digital assistant helping you, then it’s really one result is winning and everybody else is out of luck.

I think I’ve written a couple of articles on my predictions about what mobile-first indexing is going to mean for the SEO community but I think that it is going to be very much about digital assistance and about Google being able to leverage their artificial learning stuff with digital assistance. Digital assistance, I think even before we get into digital assistance, I think it’s fair to backup even further and say that right now there is not a great word or channel description for a lot of the stuff that is getting internet enabled, we could call it internet of things and say we’re optimizing for the internet of things. But really, anything that’s not a desktop or a laptop right now is being lumped in with mobile and that includes thing that are definitively not mobile like a web enabled fringe, that is not something that we’d ever put in our pocket or purse.

That’s true.

But it’s being counted as mobile because no one really knows how to handle it. But it’s those things that are either inconvenient to type on or just don’t have any kind of input mechanism other than voice that I think Google really wants to enable with this mobile-first indexing. Mobile-first is actually, in my mind, a misnomer. I think it’s cloud-first. It’s AI-first or it’s maybe conversation-first, rather than mobile-first. Because if you look at where Google’s AI is going and what they’ve been doing and how all of their digital assistants work, it’s all about the search and then the follow up questions. For instance, right now, on desktop, I think it’s desktop or phone, but definitely on phone, if you search for something and then bounce or hit the back button, it’s going to assume that you had a bad experience and it’s going to try and help you drill down to the question that you should’ve asked in the first place. You search for this, you hit a website, you didn’t like the content, you went back to the search, it’s now going to inject three or four questions that maybe help you understand why it didn’t get the right answer for you on the first try and then you can click on those three or four questions and then hopefully get another round of results that are closer to what you’re looking for. That’s the same interaction that you get or it’s a very similar interaction that you get when you use Google’s digital assistant but you don’t get the choices. For instance, on Google assistant, I can search for Portland weather, it’ll give me Portland’s weather today and then it’ll have follow up questions immediately because I don’t bounce because I can’t bounce because it’s in an assistant. It’ll say, “Do you want the weather tomorrow? Do you want the weather this weekend? Do you want the seven day forecast?” I can then click on any of those and it’ll give me another response with more questions under it. It’s trying to get a back and forth and I think it’s using the SERP learnings, what people are drilling down on in the SERPS to fuel the AI where there aren’t options and it just gives you the best options, does that makes sense?

It’s important for listeners to note that search engines can follow a train of thought. If you asked a question, “Okay Google, how tall is the Eiffel Tower?” Your next question is what are its opening hours, it will assume that you’re still talking about the Eiffel Tower. These digital assistants, there are multiples of these and they don’t necessarily have to be mobile devices. I’m within a foot of my Amazon Echo, for example. I’m not going to say that wake word because it’s going to chime in on this interview, that’s one example. We have Siri, of course, Cortana, Google. Now, what am I missing?

You got all of them. I think Google’s having this brand identity issue like many of the digital companies are right now because they had Google Now, Google Now on Tap and Google Home and Google Assistant which all appeared to be run by the same technology but with a different interface. Google Now and Google Now on Tap were about voice search and predicting what you had searched for before you searched for it. Knowing you’re a teen enough to know what you’re going to want to know or knowing your preferences enough. If you like a particular sports team and there’s been a game, they’ll tell you the score or if there’s a game coming up, it’ll tell you when it’s on TV and what channel so you don’t have to search. It seems like it’s all this big AI play to transition Google from a search company to an AI company. There’s a great quote that I have in one of my presentations about the CEO of Google, Pichai, he says, “Mobile-first is old news.” I’m paraphrasing, but he does say specifically mobile-first is not where it’s at, it’s AI-first. This mobile-first indexing, I think it’s just because it’s a catchy name.

What’s the relevance for a marketer? What do they to take action on? If they have a separate mobile site, it’s like mobile.theircompany.com and it works well, it provides a good experience, it has decent conversion rate, what do they do know?

The answer is super geeky, I’m going to give you the easy version of the answer first and that is make sure that all the mobile content has as much schema as possible. Schema, ideally in a JSON-LD format, in the head tag of the HTML rather than embedded in the HTML throughout the page because the thing is 90% of the data on the web was created in the past two years and that’s only going to continue. Google knows it can’t continue to casually crawl the web and hope that it happens upon new information to index by happenstance, it’s not scalable anymore. They’re switching to the much more heavily on things like hosting, pushing people to host with Google because then they don’t have to sporadically crawl. They know when the content changed because they host it.

You’re referring to AMP, mobile pages.

AMP is an interesting side note. I’m more referring to Firebase which is their new indexing platform. They call it an app indexing platform but it takes websites as long as the websites were set up as PWA, I told you, this is a really geeky answer.

Progressive Web App, yeah. We’re going to have to unpack this bits at a time because I think we lost a lot of people.

We can step back from that though and take it in a different direction because other than getting your mobile content ready with schema so that Google understands how your content relates to other content, and so that they don’t have to crawl the HTML, they can just pull what they need out of the header, I think the future and the mobile-first thing is actually a distancing of the requirement for content in the index to have a URL.

Let’s go back quite a bit here because I’m sure people are still wondering now who the heck is JSON-LD. We know that LD stands for link data but they probably think that’s some developer, some guy. Schema, you’re talking about schema.org which is a standard that the search engines came together and agreed upon. It’s a way of providing markup in the HTML or their ways of providing, in other ways, JSON-LD being one of them. Actually that’s an HTML too.

But not embedded.

If you think about like there’s metadata, just data about the data, there’s micro data which provides structure to the data, it’s like I can riff about some topic but if I have additional markup that provide instruction, this is a price of a product when I mentioned a dollar amount in my existential whatever riffing. That was a price, that was a product name, that was a store, that was a time and a date. If you are very specific and deliberate about providing markup or a way of identifying that this is this kind of content, this is this kind of content, and so forth then Google can do all sorts of clever things with that meta information.

And it’s much faster and more efficient for them.

There is less ambiguity. If you go back to Tim Berners-Lee’s original vision for the World Wide Web and Semantic, the Semantic Web. Tim Berners-Lee, the inventor of the World Wide Web thought that computer devices would be talking to each other more than humans and I still believe that it is going to pass. It may already be but if computers are going to talk to other computers, there needs to be more structure. The stream of consciousness riffing can’t really work that well. I’m getting very meta here about it but now, based on that idea, mobile-first indexing fits into the picture in one way and we start to describe its schema in another way, responsive design, another way, and then there’s dynamic serving and so forth, there’s AMP which we haven’t talked about yet, accelerated mobile pages, I’m sure we’re making our listener’s brains hurt right now.

Stephan, I never expected you to be my geek interpreter. I always expected it to go the other way.

I am pretty geeky, that’s true. I actually have another podcast that’s called Get Yourself Optimized so that’s very ironic that you mentioned that. Let’s start with something that’s very actionable for folks. We’ll come back to JSON-LD in a bit when they’ve settled down a little bit. What can they do to get mobile ready because everybody is moving to being on mobile devices, Google said that there are more searches on mobile devices than there are on desktop and that’s never going back, it’s important that you tailor your experience to mobile devices, that you tailor your SEO to mobile devices even if you believe that your customers, your prospects are not on their phones visiting your website, Google is visiting your website as essentially a mobile user. This is important because you cannot just tell Google, “I don’t care about you.” Everybody needs to care about Google. Let’s talk about AMP, what the heck is that and why do we need to take action on that immediately even, let’s say, an ecommerce site?

AMP is an interesting thing because actually [00:18:13], who you already mentioned, he said that AMP is not yet setup properly for mobile-first indexing which is interesting. AMP stands for Accelerated Mobile Pages. It’s a subset of HTML called AMP HTML and is very limited, kind of like the original version of HTML was supposed to be. Over the years, HTML has gotten a lot broader to include a lot of different things and browsers have gotten a lot better to include lots of different code that’s not just the HTML. The browsers try so hard to handle all these different kind of code but it makes things very slow, that’s especially bad on mobile devices. Google worked with some partners to come up with this AMP HTML which is a limited HTML, also limited style sheets or CSS, and limited JavaScript. It’s funny because we had mobile pages, m. pages and then Google said, “No, no, no, go responsive design, one version of the page.” Everyone did that and the responsive design pages were full of so much code and were so inefficient that Google said, “Wait, maybe separate pages is not so bad but do it this way with this AMP HTML. Take all your pages, make an AMP version of them or just switch all your existing pages to AMP HTML.” AMP HTML is super fast because all of the elements that you can include are written and must be included very specifically as they are but they’re written by the best developers who know how to make speedy stuff and you don’t got to be creative and make your own stuff up, you have to stay within the lines.

It’s a very limited platform. You don’t have the ability to do some tracking for example, and some functionality that might be on your regular mobile site, your mobile experience if you’re responsive design, it’s the same website, mobile and desktop, but the experience changes because of the CSS code, the Cascading Style Sheet code. You need to limit it even more using AMP because now Google says, “If you want to play in our Sandbox and have the little Lightning Bolt logo and the higher rankings and all that sort of stuff, all the benefits because it’s a better experience for mobile users to get this Google hosted faster experience of your content, you need to follow all these rules and they’re very restricted.

The other part/the other restriction is that you’re strongly encouraged to host all of your external content in Google’s Cloud hosting. They say that you can work with other client hosts or other web hosts but that’s really not come to pass so much. It’s very difficult to implement that way but quite easy if you’re hosting your content in Google’s Cloud. Again, this helps them know when there’s new stuff because they see the new stuff appear when you upload the new page and they know when at least images and videos and external element change because they’re hosting it.

You can still track visits and conversions and so forth with AMP pages, right?

You can. The thing that most SEOs are open arms about is that when users get to the page, they’re actually on a Google hosted version of the page. Even though you go to the effort to build the second version of the page like in an AMP directory on your primary domain or something like that, when that page ranks in a Google search result like a carousel and someone clicks on it, it’s hosted by Google. This seems like it makes it hard for people to link or share the original content and it makes it hard for the original content to get any kind of SEO value from those interactions which I think was probably maybe not intentional but shows where Google’s brain was at in terms of the future of SEO. It’s not about links. It’s probably not even about shares. It’s about engagement. If they’re hosting the AMP page, they don’t care if SEOs are getting in a fuss, they can actually see the engagement for themselves. I think in the future iterations of Google, their ranking factor is really going to be engagement. We’re already seeing that with app indexing and stuff like that in the apps and in the appstores. It’s about engagement, it’s about star rankings and reviews, but it’s also about engagement. It’s minimally about keywords, to some degree, there are keywords there but once they’ve got the consideration set narrowed down, it’s about engagement.

We’ll definitely have to come back to getting your mobile app ranking higher in the different app directories, the Google Play and the Apple Store, the App Store, let’s go back to this. Google is hosting your page, it’s in a directory on your site but Google hosts and that’s what’s being served in the search results when you have the little lightning bolt, as you say like an example, it might be in a carousel in the Google search results but it’s not just the fact that it’s being hosted by Google, it’s also that it is a Google URL. When people link to that AMP page that you worked so hard to create and you had to be so restricted in what you could do on that page, anybody linking to that AMP article that you wrote, it’s linking to google.com.

I think that they’ll get this all sorted out soon. I think actually the frustration with this has been what’s held the launch of mobile-first indexing up, there is an API that Google has that’ll allow you to correspond Google version of an AMP page to the original or vice versa but I think it’s technically quite hard to sort that out while still doing everything that they’re trying to do, we’re still getting all that engagement data but making the SEOs to feel good about it, all that. They have improved it a little bit. We’re now on an AMP page, there’s an extra button that has a link icon and you can get the link to the original content but they’ve said that they have no intention of serving the AMP pages on the original domain.

Which makes sense. Why would go from a really robust, fine-tuned environment such as Google’s hosted Cloud to a lot of real mess out there with all these different web hosts, some of them are very secure and very robust and fast and some really suck, why would they switch to that?

Yeah, exactly.

Let’s go back, talk a bit about AMP and the action for people is to follow the instructions that Google provides and go to ampproject.org, that’s the URL. You follow the instructions, you go through the process, hire a developer or whatever to create an AMP version of your site and then the next action would be, let’s say that you have a mobile site and it’s separate from your main site that’s m. or mobile.yourcompany.com, you probably want to move to the responsive design or maybe dynamic serving but probably responsive design, let’s talk a little bit about that.

Yeah, you would probably want to move to responsive design just because that’s where Google believes the future of the internet is. That’ll make it easier to do everything else like Google’s pushing for because AMP is responsive and then Google is also pushing on the Progressive Web Apps which are websites that have taken all the right vitamins to do more cool stuff than most websites do and they’re pushing hard on that. That’s also based in a responsive design paradigm. That’ll mean that having a mobile page as separate mobile page creates a lot of questions, when do we serve the mobile page? Do we serve it to tablets? What about when people try and show that on a web connected TV or a fringe or in an android auto situation, it’s becoming more and more questions. Having a rule set in Cascading Style Sheets, on one version of the page will end up being more scalable for most companies.

If you do still have a mobile site, I see this mistake a lot is not correctly by directionally linking the two sites together for Google like having the real alternate tag, pointing to the mobile site from the desktop site and not having a real canonical on the mobile site pointing to the desktop site.

If you’re doing that to follow the newest requirements, you would also want to make sure that any schema that’s on the desktop version of the site is on the mobile version and the title tag in description are carried there too.

They have to be the same. But better to just switch to a responsive design. Dynamic serving, separate from responsive design, gives you the ability to have different HTML. The URL stays the same but the HTML is different. It can be a much more streamlined version of the page. As you said earlier, there’s a lot of bloat in the code with responsive design, there’s a lot of stuff that’s not even rendered for mobile users, it’s just there and it slows down the page and does Google realize that AMP was something they needed to do? But dynamic serving has some side effects, it might sound good. I can make a much faster mobile experience by changing the HTML code but it’s not an ideal situation, why is it?

It’s definitely tougher to test, tougher for Google to crawl and just in general, error prone. If you have a really sophisticated development team, it is an option. There are different levels of dynamic serving, you can dynamically serve entirely different HTML or you can modularize things and choose to just not send some things based on devices requesting it or you can switch in smaller versions. For instance with videos, you can send Flash videos to desktop and laptop users and send HTML5 videos to mobile users, that’s a really common use case because Flash videos do end up sometimes being faster with better tracking but they don’t work on mobile, things like that.

With Flash not even working on any iOS device, seems like that decision by Apple was the death now for Adobe Flash.

There are a lot of silent battles going on, I think, that are like that. Adobe’s video platform and monitoring system that many big companies use prefers Flash because Adobe is a Flash product. They have HTML5 and they allow it to be used but they make it very difficult and they don’t update it as frequently, they’re still updating their Flash modules. The big companies that have lots of videos still lean hard on Flash whenever they can because they get better metrics and they get better engagement because it’s always faster. There’s the silent battle with apps and app indexing. Most people don’t realize this but Google created the app indexing API to help people get screens within their apps, able to surface in a Google search result. They were working with Apple and then something went wrong, we don’t know what and Apple started penalizing apps that were in the AppStore that leveraged the API. There are things that look like app indexing for iOS but it’s actually not, it’s somewhat different and that could get really complicated so I won’t explain it here unless you really want me to. But as it stands right now, Google is really not supporting app indexing for iOS anymore but there is no big announcement because it’s the silent battle and it’s hard to explain, probably because it’s very much a turf war in both cases.

Most people don’t realize this but Google created the app indexing API to help people get screens within their apps, able to surface in a Google search result. Share on X

Yeah, there are a lot of turf wars going on in the internet space. App indexing, we’ll talk more about it in a little bit. We’ll come back to it. But the idea here is if you are, let’s say Yelp, you have a ton of content and it’s all available inside of the mobile app, the Yelp app, all that content should be exposed to Google for indexing so it shows up in the search results so you could end up doing a search on Google, finding something that is deep within Yelp’s database and you end up, when you click on it, going directly to that screen inside of your Yelp app that’s installed on your phone.

Right, if you have the Yelp app. If you don’t, then you go to web. The difficulty is that it’s almost like another m. site because you’re having to duplicated different versions of your content in multiple platforms. If there is no corresponding web content right now, Google won’t rank it. They’re trying to rank app only content that doesn’t have a corresponding web element but it’s in a limited beta, they opened it up and they said they took it out of super limited beta and just made it an invite only beta or they said they opened it up but it’s invite only, it’s still in beta, it seems like. But companies like hotels tonight or things like that that don’t have corresponding web content want to get their stuff to surface but Google can’t handle it serving such different things yet if there’s no fallback plan for people who don’t have the app. What they’re trying to do is host little bits of the app in the Cloud, in what’s called Android Instant Apps. If you don’t have the app installed, you can interact with a piece of the app because they posted the app in the Cloud and that’s how they allow it to rank but that’s all still being tested. But if and when that’s successful, if Safari doesn’t somehow block those URLs, iOS users can use Android apps in the Cloud, it will really minimize the need for people to download an entire app just to get a little bit of information. It’ll be a game changer.

Let’s circle back to one point about dynamic serving that I think is important if folks are going to go down that route or already have. There is one nuance that’s critically important and that is having a very header set in your HTTP headers. Cindy, do you want to say anything about that?

Yup. I should’ve said that earlier. It’s important because it tells bots that there is content of various based on the user agent. Google has said that that’s part of their requirement. In my own testing, I found that it’s the best practice that’s sometimes optional, I don’t know, what have you seen, Stephan?

Whenever I’m auditing a client’s website and I see that they’re using dynamic serving, a lot of times they’re not doing a very header and I always tell them that that’s something they need to implement and it’s super easy to set that up.

Yeah, it’s easy. I have seen people have success without it, that’s the only point that I was making, but yeah, it’s totally the best practice.

I don’t think you’re necessarily going to get penalized because of it because a lot of sites don’t do it. They just didn’t know any better but you really should. We covered that topic. Let’s come back to JSON-LD because I don’t think we really defined that for folks yet, we joked that that might be the name of some guy but it’s not, it’s related to schema, let’s explain that.

JSON-LD stands for JavaScript Object Notation, which probably doesn’t help anyone, but what it means is it’s like a JavaScript way of including markup or schema so it just uses JavaScript and you usually put it at the top of your HTML in the head tag which makes it easier for Google to find all the information that they need. It’s just a different protocol, most of the schema instructions that are out there are available in HTML or JSON-LD. JSON-LD seems like it’s now definitely being preferred by Google and the LD is what I think is important there. The LD stands for linked data, it’s not link data, it’s linked data. It’s allowing Google to understand your content in the context of everything else that it has in its index. If we talk about farm animals, it will know that a cow is generally included as a farm animal so it’ll know those relationships. Even if we don’t use the word farm animal, if we’re talking about cows, because Google is crawling all these JSON-LD and lots of times when people talk about farm animals, they talk about cows, it’ll know. It’s like it’s building Google semantic understanding of the language.

JSON-LD is preferred over putting schema in HTML format but what’s the takeaway that marketers need to know about this from a mobile marketing standpoint that they need to switch from using the HTML form of schema to using JSON-LD?

It should be on the roadmap but I’d be interested to hear, Stephan, what do you think on this is I think that it seems that the JSON-LD could just be hosted separately rather than putting the head tag but that would freak too many people out, that would be easier for them to crawl so they wouldn’t even have to go into the head tag because then you’re essentially turning your website into an API.

You going to realize too that some of our listeners don’t even know what an API is, Application Programing Interface. We got a diggy fist a bit.

The API, Application Programing Interface, that’s how computers talk to other computers without humans.

It’s like a protocol or a set of rules, instructions. It’s a way that you can have your program talk to another program on the internet such as Google getting data out of a Google search console through their API. I know we have not too long left in this interview. I want to differentiate for our listeners regular mobile apps from Progressive Web Apps, PWA. Isn’t PWA the future and creating your own mobile app is past, it used to be the big thing like, “Do you have a mobile app?”

I’ve always thought that native apps were passé because they’re so limited. The native app is what you would go and download in the Google Playstore or the App Store. The reason I have always thought they’re passé is they only work on that device. If you build a native app, you’re either building for Android or iOS. You could build for both but it’s two separate apps, separate code sets, separate development teams for the most part. You have to do everything twice. But if you make something work on the web, it works anywhere there’s a browser. I’ve always loved web. PWAs make the web more like a native app. A Progressive Web App is essentially, like I said earlier, it’s a website that took all the right vitamins and that’s a quote from the lead of the PWA team at Google. I can’t remember his name but I don’t want to take credit for the quote. But it’s basically you take you responsive design website and add a couple things, the two main requirements that are different are an app shell file which is called an App Manifest and a service worker. A service worker is a bit more complex but it basically choreographs, it’s a middle layer that choreographs everything that happens on the website to make it as fast as possible. The other thing that those two things get you is the ability to recognize when someone’s come back to your website a couple times and show an ad, let’s say on the first time you revisit the website that’s more than five minutes apart, if I visit it today and tomorrow. On the second time it might show me an ad that says, “Hey it seems like you like the site, you’ve been here a lot, do you want to download the app?” If I say yes, when I hit download, it’s not actually downloading a native app, what it’s downloading is the app manifest or the shell. It’s downloading the service worker too, it means when I’m interacting with the sites, the app shell and the service worker are on the phone, the loading becomes even faster and more efficient. Also, since we have the service worker managing all the loading, that service worker is caching all of the stuff so that the website/app can work even if you’re not connected to the internet, it’ll only work for the stuff you’ve already seen because it’s got that in the cache but that’s still pretty cool.

It’s very cool. A more old school equivalent to this would be let’s say that you have a website and you want to speed up the download speed for users, you could take all the in line JavaScript and CSS, put that in separate external files, separate .js files, .css files and the functionality still stays the same but your computer will cache those files and then when you’re on different pages of the website, those JS and CSS files don’t need to reload, they are already cached and the rest of your surfing experience on that site is definitely faster, that’s an old school equivalent to having this app manifest and service worker cached or stored on your phone because you’ve been to this same Progressive Web App more than once in the last whatever time period, you said five minutes or whatever.

If you’re used to clicking around on websites on your phone, one of the things that slows people down the most is that every time you click on a new URL, for less sophisticated websites, when you click on a new URL, the whole page has to reload even though it’s a lot of the same stuff. With PWA, they lean more heavily on the server and they don’t require the URL change for the content to change even though that’s a different topic from an SEO perspective but the content is just sent by the server often. Since you have the app shell loaded, you’re not reloading all those different elements all the time, you’re just getting the text and maybe if there’s an image or a video, you’re getting a minimal amount of stuff off the internet that you need to update the experience, you’re not reloading and re rendering the whole page every single time, just the most minimal amount of content possible. That does make them super fast.

What is Fire Based then in relation to PWA, Progressive Web Apps.

Fire Based is something that Google’s had for a while and they have marketed it a lot of different ways. They’re struggling to market it. Some groups at Google are calling it their app indexing platform. What it does is it allows you to upload Android apps, upload iOS apps and upload PWAs. You then have the ability to map across contents. Let’s say you have one piece of web content, the same content in your iOS app and the same content in your Android app. You can create the relationship between that one piece of content on the three platforms there and that helps them give you really, really rich attribution data per user and per device because right now they’re struggling in Google analytics to show if I checked in on the app on my phone but then used Facebook web browser when I got to my computer and then have an Android tablet on an iOS. Many people are on all three platforms and using them interchangeably but Google analytics struggles to show that from a per person user or from a per page or per piece of content perspective, how is this content working. It helps figure that out and they’re allowing PWAs in but they’re not allowing regular websites in. The bare minimum to call yourself a PWA and get in the firebase is to add a service worker and an app manifest. Those two things actually aren’t very hard and it does seem like they’re setting us up for this carrot and stick situation where if you do the minimum and turn your existing responsive website into a PWA by adding an app manifest and adding a service worker file, there are just files that you add at your root directory and then link in the head tag. If you do that, then you get to switch your data. That’s better than Google Analytics. It looks very, very much like Google analytics but it’s more data, it’s better data and it’s free.

Bottom line for our listeners, if they were considering having a mobile app, they should do PWA instead.

I would say yes, especially if they have a rock and roll mobile website. I would keep the budget that you were going to pay the developers for the native apps and use it to improve the mobile site and make it PWA friendly. There are even ways, this might blow too many people’s minds but I’m going to tell you anyway. You can use AMP HTML in your PWA and then it’s screaming fast. The main take away there is anyone can use AMP HTML. It doesn’t have to be on an AMP valid page. It’s open source code that’s super duper fast. I’m encouraging lots of clients even if they’re not trying to rank in AMP carousels to use AMP HTML wherever they can including if they’re building PWAs and you get fastest, most beautiful experience ever.

That’s awesome advice. The reason why they should try away from a native mobile app if they were thinking of investing in that has a lot to do with where the future is heading but also today, if you look at the stats on mobile app usage, it’s crazy how little people use apps other than Facebook, Facebook Messenger, and a few others. It’s so tiny, the amount of app usage for typical users than a main three or four apps.

Absolutely. Facebook and YouTube and Netflix and Hulu are throwing the off the app stats because those are long engagement app experiences that people love but the average number of apps searched for by users on iOS and Android per month is zero. They’re not looking for apps. They’ve got everything they need.

I, for one, have 100 apps easily on my phone and I never use any of them except for maybe three or four. I’m always using Waze. I’m using Yelp. I’m using Facebook, Facebook Messenger, Skype. That’s about it.

Everyone has their few and if you think that you have a chance of being one of those few, kudos, go for it. We’ll help you, MobileMoxie. We can get you ranking in the App Stores but if you don’t think you can be one of those that are really routine engagement situation and especially if you don’t have anything unique that happens in the app that requires an app, I would head towards PWAs.

As far as ranking in the App Stores, if you do have a mobile app, we won’t spend so much time on this because most of the listeners probably don’t have mobile apps but keywords are important and the name of the app and then the description and so forth, engagement’s important.

Star rankings.

Star ranking, the number of reviews and the average score.

And the sentiment.

What if you have a really low score, let’s say three stars which is bad, I wouldn’t go to a restaurant that was three stars in Yelp. Would people install an app on their phone that’s three stars, I don’t know, I don’t.

Yeah, maybe, it depends on if it’s really unique that does exactly what they need but is sometimes buggy or maybe it just launched and who knows. But there are ways to mitigate the star rankings, the way best to mitigate bad star rankings is to republish a better app. But if you can’t do that, there are other sneakier ways that probably are too involved. They’re not super sneaky, they’re totally legal and legit within the guidelines of the stores but stuffs like creating a reviews dialogue to prompt people to give you reviews especially when you know something good just happened like they just logged a run in their run tracker and you’re like, “Hey good job, you killed it on that run, do you want to review us?”

Even Google does this like on the Waze app which is owned by Google. It’s like, “Hey do you want to give us a rating review?” No, I don’t but thanks for asking.

If you asked at a wrong time like they’re about to go on a run and they haven’t left yet, that’s a bad time.

Let’s do a quick little lightning round of few things for people to do that would be applicable I think for everybody. Should they check to see what their mobile page speed is? This is a softball here for you.

Yeah, pagespeed is important. Google has a new tool but it’s very much giving the same scores as the old tools, the same things appear to be important. The old tool is called Google Pagespeed Insights, the new tool might be called something like next, I don’t even know, they link to each other. Check out your page speed, check out still the mobile friendly test even though it doesn’t seem mobile friendly in the search results anymore, you still have to pass that test. Make sure either in search console or testing URLs, one of the time that you pass.

Anything else that would be a no brainer? Do they want to check their page speed for mobile on anything other than pagespeed insights or next or GTmetrix for example or Pingdom or anything like that?

Pingdom is fine, I use webpagetest.org because it has a lot of different options, where you’re testing from, what kind of phone you’re testing from, stuff like that. The other thing is if you’re a local business and you want to check map results on mobile. MobileMoxie, it’s not pagespeed but map results are super important and the only tool out there that allows you to choose a bunch of different phones, Android and iOS and set a location for your mobile search and see what the search results look like, MobileMoxie is the only one that’s got that right now and people are loving it. You can see what the search results look like from a particular zip code and we’re about to add something where you can drop a pin and say search from right here telling what the search results look like. That’s super important local SEOs.

What’s the URL for that tool?

It’s on the MobileMoxie website, I don’t know, hold on I’ll look. But it’s called the Search Simulator, the MobileMoxie Search Simulator. We also have a page emulator, if people care about that too. You can test your landing pages on a bunch of different phones.

Just so you know, if you’re on the techier side or if you’re Stephan Spencer, those tools are both also available in APIs to put in your own site or in a tool site reporting dashboard thing, whatever you want.

That’s super awesome and geeky. One last question, deep linking we didn’t talk about that and tracking app opens and things like that through these deep links, what the heck is that?

Deep linking, you’re really not getting a lot of deep linking information if you’re doing it for iOS because of the turf battle that’s going on right now, deep linking is really only a thing for Android. There’s a way to do deep linking on iOS but it doesn’t particularly help with Google SEO. It does help with Siri, Safari, and spotlight search, it’s great there but not a lot of people are searching there. Deep linking allows you to connect the web version of your content with the app version of your content. In search console, you can set up your Android app to see the engagement and all of that. It’s not too hard and it can all be done pretty easily with an API but Google is also crawling the Android stuff somewhat organically, not a whole bunch, it’s better to use the API. We talked about app indexing and deep linking are very closely related but they are slightly different. You can deep link to content even if you don’t want it to get indexed. For instance, if you are Yelp and you’re sending out a newsletter then highlight certain restaurant or content, you can include the web link and include a deep link to your iOS or your Android app and if the people open email on their phone, it will open the content in the app, if they have it installed. That’s where deep linking is still working for iOS but app indexing isn’t.

I think we made our listeners brains hurt which I think is a good thing but I’m not quite sure. My team will create checklists of actions to take from this episode. Definitely go to marketingspeak.com especially for this episode which has a lot of geekery and probably has overwhelmed you. I’m talking about you, the listener. Go to marketingspeak.com. Go to this episode with Cindy Krum and the show notes will have the links and stuffs then click on download the checklist and that will give you 10 things to do than  will help you do better with your mobile marketing and mobile SEO. If anyone wants to work with you, Cindy, what’s the best way to get a hold of you?

You can email me [email protected]. You can find us on the website, I’m on Twitter, we’re just all over the place, not too hard to find.

Thank you so much, Cindy. Thank you, listeners. We’ll catch you on the next episode of Marketing Speak. This is Stephan Spencer, signing off.

Links and Resources:

Your Checklist of Actions to Take

☑ Find out how fast my mobile website is using Google’s new mobile page speed tool.

☑ Choose a responsive design or theme that has good mobile rendering; bad responsive design and a high bounce rate could push down my overall site rankings.

☑ Make sure that all of my mobile content has as much schema.org markup as possible with a JSON-LD format in the head tag of the HTML instead of being embedded in the HTML throughout the page.

☑ Create an AMP version of my site. The accelerated mobile pages offer a pared down version of HTML, CSS, and JavaScript that runs super fast.

☑ Make sure I have my mobile and desktop versions connected using rel=”alternate” and rel=”canonical” tags if I have two separate versions for mobile and desktop also make sure the schema.org information and title tag and description are the same.

☑ Use the Vary HTTP header as a best practice when dynamically serving different HTML elements within the same URL.

☑ Use PWA to rely on the server for faster loading through caching using the manifest (shell) and service worker. This makes the web act like a native app.

☑ Choose PWA over a native app and use AMP HTML to have the fastest app possible.

☑ Map across content on different platforms using Google Firebase for rich user attribution data to improve analytics. I must have an app manifest and service worker file to be in Firebase.

☑ Learn more about how to speed up my site and check out tools like the Search Simulator on Cindy Krum’s website Mobile Moxie.

About Cindy Krum

Cindy Krum is the CEO and Founder of MobileMoxie, LLC, a mobile marketing consultancy and host of the most cutting-edge online mobile marketing tool set available today. Cindy is the author of Mobile Marketing: Finding Your Customers No Matter Where They Are, published by Que Publishing and now also available in German, Italian, Korean and Chinese.

Cindy is an active member of the search community and has been published in Website Magazine, Advertising & Marketing Review, Search Engine Land, Search Engine Watch, Marketing Land, SEOmoz, and Search Engine Strategies Magazine.