DISCLAIMER: This post is written as a live blog from Mozcon. There may be typos and grammar to make my high school English teachers weep. Please excuse those … it’s a fast-paced conference with back-to-back sessions and no time for proofing or even proper writing.
Coming up after lunch is the mobile guru Cindy Krum of Mobile Moxie who was telling us to ready for mobile about 5 years before anybody actually did. Today she’s chatting app indexing and Firebase.
She reminds us hat we don’t need to know how to build mobile to know it’s important and know what to do with it.
Mobile grew in stages:
- In the beginning there was nothing. No indexing of apps.
- Then Google decided to crawl JavaScript to they could index JS.
- Following that they taught their crawlers to crawl Android Apps followed quickly by iOS apps.
- At this stage the crawling is primitive but they’re indexing apps.
So we’re at the stage of semi-enlightenment. Content is indexed but in association with web content.
Now we need to see the future. So what are the indexing mechanisms?
1 – Web apps. They live on the internet. Basically these are sites that rely on JavaScript and Ajax. Ajax has been around fo ra bit and now there are code bases for it that allow websites to function like native apps. The problem however is that pages are getting bloated and inefficient trading off user experience for function.
It does important things like autosizing pages for screen sizes. What we’re seeing happen though is that we’re getting smaller screens and larger filesizes.
After removing the “Mobile friendly” tag on mobile results they have tested a “Slow” tag on slow sites. Clearly this is imporant.
Note: She meitones that rel=”alternate” makes JavaScript redirects acceptable in Google’s eyes I did not know that.
Next she’s chatting Progressive web aps. They make things FAR faster similar to AMP. This requires HTTPS however. You also need a Web Ap Manifest. The file tells you the details of the web app. (the titles, icons and where it starts, etc.)
You can send push notifications. Websites can’t but web apps can as they’re on HTTPS so they can’t send malicious code.
The core of these is that you can download the PWA (not the app – just the manifest and virtually instant) which gives you an app icon just like a native app at which time it can load in its own shell. This is awesome.
Another handy function is that you can function with it offline allowing you to interact where you couldn’t with a regular site. This also makes it far faster than a site as everything can be cached.
The are referred to as “websites that took all the right vitamins”.
This solves the problems with apps and the problems with websites. People spend 3x longer on the site, they engage 40% higher, the convert at 70% more and it takes 3x less data.
The problem is that it’s hard o index.
Further, most have ignored SEO. They’ve been built by developers and never SEO’d so make sure that the fancy development doesn’t kill your SEO.
2 – Regular Apps
Indexing is about giving apps entry points. Since they don’t have links you need to give them URLs to give Google something to sink their teeth into.
Native apps are faster BUT they have minimal reach. The number of apps downloaded from the app store is, on average, 0 per person. People aren’t looking for apps so it has low reach.
Apps represents 86% of time people spend on apps. That said, 80% is Facebook, YouTube and Facebook Messenger.
Also – 66% of all purchases n mobile happen on the web.
The problem is solves b making the app more discoverable. To do this you update your app so it follows HTTP or HTTPS app schemes (a URL for apps). If this matches what’s happening on your website you can create a union between the two and Google can evaluate and rank it.
It’s not enough to update the app – you need to create a map. There is one for Apple and one for Android. You then host these at the root directory or in a .well-known folder. This will get you indexed and make you more discoverable.
The problem is that the association HAS to be to canonical on the web. If you redirect a page and not the map you’ll break it and lose the weight and indexing.
She then discusses the REAL problem – the teams don’t talk. SEO’s don’t chat with dev, etc. Also, they use different works for the same thing so even when they do communicate it isn’t always understood.
To combat this Google launched Firebase.
Google has not communicated this to the SEO community. Basically it makes the crawling and indexing easier by giving apps specific entry points and they even host the app themselves to make indexing easier and faster.
It also gives Google the ability to display dynamic links.
What does this mean?
- Cindy believes as thing progress Google will be able to be better able to index the content
- You’ll get a rankings boost for using Firebase
- Development across platforms will get easier
- Android Instant Apps will cut out App stores. You’ll just be able to find them in the SERPs or sites and grab the app from there.
- Using Google Bigquery both you and Google can monetize better.
A big big problem is that Firebase is scary. Also developers will worry that Google will abandon it and leave them high and dry. People also worry about Google using your data against you.
Firebase is also difficult to set up. No individual can set it up easily and worst of all … the documentation is brutal.
So should you use Firebase?
Maybe. But you should be paying attention and working on native app indexing.
Big benefit to Firebase, it becomes your CRM, CMS and CDN. You also get remote config.