Will Critchlow — ‘Practical Advice for the Future of Search’

Transcript

1. brought to you by... PRACTICAL TIPS FOR THE FUTURE OF SEARCH WILL CRITCHLOW
2. Tactics to cope with change Grouped into 4 strategies
3. Strategy: desktop is the poor relation to mobile 1
4. We’ve been too focused on this: vs.
5. -- old computer science saying via Ben Evans a computer should never ask you a question that it should be able to work out the answer to
6. While forgetting: It can take photos
7. While forgetting: It knows where it is It can take photos
8. While forgetting: It knows where it is It knows who your friends are It can take photos
9. While forgetting: It knows if you are walking, running, etc It knows where it is It knows who your friends are It can take photos
10. Never mind that... It interacts with the world (beacons, pay, NFC)
11. Never mind that... It’s personal, signed-in, and taken everywhere It interacts with the world (beacons, pay, NFC)
12. Never mind that... It’s personal, signed-in, and taken everywhere It interacts with the world (beacons, pay, NFC) It has natural multi- touch
13. Never mind that... It’s personal, signed-in, and taken everywhere It interacts with the world (beacons, pay, NFC) It has notifications It has natural multi- touch
14. -- mobile first by Ben Evans it's actually the PC that has the limited, basic, cut-down version of the internet … it only has the web
15. LET’S TALK TACTICS
16. It knows where it is How can these things help you? It knows who your friends are It’s personal, signed-in, and taken everywhere It interacts with the world (beacons, pay, NFC) It has notifications It has natural multi- touch It knows if you are walking, running, etc It can take photos
17. I talked about mobile content marketing last year (link)
18. We have to do something about download sizes
19. this article is 250 words -- Amit Singhal at Re/code’s Code/Mobile conference talking about this article
20. that's under 2kb -- Amit Singhal at Re/code’s Code/Mobile conference talking about this article
21. -- Amit Singhal at Re/code’s Code/Mobile conference talking about this article you know how many bytes someone had to download from recode's server to render this article?
22. -- Amit Singhal at Re/code’s Code/Mobile conference talking about this article 2.5 megabytes
23. For every byte of content
24. You have to download 1250 bytes
25. Not just re/code (see this NYT article)
26. Apple News and Facebook Instant Articles are walled- garden responses
27. Apple news within the walled-garden (dev resources)
28. Facebook instant articles very similar (dev resources)
29. Google’s response is AMP (Accelerated Mobile Pages)
30. Launched with tons of publishers on board
31. What is AMP and how does it work?
32. Try out Google’s vision by going to: g.co/ampdemo on your phone
33. Click on thumbnail
34. “Instant” page load
35. Swipe between pages
36. What is an AMP page? AMP HTML is a subset of HTML with only specific JavaScript “components” available, and using a standard JS toolkit. Start here: Guide to creating an AMP page
37. Cached on gstatic URL Designed to be cached aggressively
38. Cached on gstatic URL Designed to be cached aggressively Initially render only the viewable area
39. Cached on gstatic URL Designed to be cached aggressively Initially render only the viewable area amp-img replaces img Loaded by JS
40. Cached on gstatic URL Designed to be cached aggressively Initially render only the viewable area amp-img replaces img Loaded by JS Behind scenes, 100kb .js file saved locally
41. Debug on the desktop by using inspect element and opening the mobile emulator
42. Canonical and amphtml links connect them http://www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet-apple-macbook-pro Desktop web
43. http://www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet-apple-macbook-pro/amp Canonical and amphtml links connect them rel=“amphtml” http://www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet-apple-macbook-pro Hosted amp
44. http://www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet-apple-macbook-pro/amp Canonical and amphtml links connect them rel=“amphtml” http://www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet-apple-macbook-pro rel=“canonical” Hosted amp
45. https://amp.gstatic.com/v/s/www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet... Canonical and amphtml links connect them Cached amp
46. https://amp.gstatic.com/v/s/www.theguardian.com/technology/2015/oct/07/microsoft-surface-book-laptop-tablet... Canonical and amphtml links connect them rel=“canonical” Cached amp
47. Try out AMP The downsides are smaller than Instant Articles Should be easy dev on a good CMS
48. You generally make things on computers
49. Buzzfeed leads the way With mobile-preview in the CMS by default Preview
50. -- Jonah Peretti, founder of Buzzfeed Talking about (among other things) their CMS - from his strategy note We build the whole enchilada
51. Understand app search 2
52. Watch Amit Singhal on stage (link) Mobile, mobile, and mobile
53. “App search” is really 3 things
54. 1. App Store Optimisation (ASO)
55. 2. Public index - searching app content
56. 3. Personal index
57. “Hello Vipul”. From the personal index 3. Personal index
58. 3 things
59. LET’S TALK TACTICS
60. ASO is the least interesting
61. ASO is the least interesting App searches are like searches for websites not web pages
62. ASO is the least interesting App searches are like searches for websites not web pages It’s more like Yahoo directory than Google - brand names and categories
63. ASO is the least interesting You can’t dominate unless you are very successful and if you are extremely successful, the upside’s small App searches are like searches for websites not web pages It’s more like Yahoo directory than Google - brand names and categories
64. Still, you should do it (see this presentation)
65. The public index is the big opportunity For all the usual “long tail” reasons. As well as typically being non-branded
66. At simplest, just extends web search Note web URL
67. A note on information architecture
68. www. Too many used to think of websites like this m. (totally different URLs)
69. m. www. Now most map or share URLs: rel=alternate mapping
70. m. www. rel=alternate mapping app views But we still too often think:
71. m. app views www. rel=alternate mapping Which evolved to Deep linking
72. Same URL works on desktop, mobile web, and in your app Now we should be thinking
73. Right now, Google search is the most interesting opportunity
74. Make sure your app can open links As of iOS9, the recommended approach is http links on both platforms 1
75. Register your app iOS9 uses CocoaPods to add GoogleAppIndexing support Android only needs to be associated via Search Console (if http URLs map to web URLs) 2
76. Used to require schema.org(*) (*) or rel=alternate, or applinks, or sitemap
77. -- Vincent Wehren, Bing, May 2015 [Emphasis mine] “we’ve already started analyzing the web specifically for App Links and actions markup”
78. Bing still needs markup
79. Introduction to app indexing APIs
80. Reveal users’ activity in your app
81. Three good reasons to use the indexing API: 1. App-only views 2. Personal index 3. Reveal app engagement (4. add meta information)
82. It’s not really about Android M
83. ...or
84. On Android, it’s the Google API that’s interesting
85. // Define a title for your current page, shown in autocompletion UI String title = "App Indexing API Title"; // Construct the Action performed by the user Action viewAction = Action.newAction(Action.TYPE_VIEW, title, WEB_URL, APP_URI); // Call the App Indexing API start method after the view has completely rendered AppIndex.AppIndexApi.start(mClient, viewAction); The API has changed since last year Source: Google
86. Indexing actions rather than just views (docs)
87. This extends into voice actions and much more (Did you know you can hear all your voice searches at history.google.com?) OK, Google
88. Now on Tap cuts both ways Driving people into and out of your apps Source: Google Yelp and OpenTable are here because they have indexed deep links to this entity
89. We expect there to be both a Google & an Apple API on iOS
90. There are actually two Apple APIs
91. CoreSpotlight (indexes content for you alone) NSUserActivity (indexes “bookmarks” public and private)
92. From personal index CoreSpotlight Personal index only - content-focused
93. Personal index: not just about mobile
94. NSUserActivity: Closely related to Handoff
95. a lightweight way to capture app state so that it can be restored later Apple developer docs
96. eligibleForPublicIndexing Property eligibleForSearch Property Private by default
97. when users engage with your app’s public activities in search results, it indicates to Apple that public information on your website is popular Apple developer docs
98. which can help increase your ranking and potentially lead to expanded indexing of your website’s content Apple developer docs
99. I think this mainly shows that Apple hasn’t met any blackhats yet
100. Watch out for these pitfalls Ensure users can get straight to app content without registering (first click free)
101. Watch out for these pitfalls Ensure users can get straight to app content without registering (first click free) Enable the new iOS9 back button to allow users to go back to the SERP
102. Watch out for these pitfalls Ensure all appropriate app view URLs are allowed in robots.txt Ensure users can get straight to app content without registering (first click free) Enable the new iOS9 back button to allow users to go back to the SERP
103. Checklists
104. Must-have Avoid pitfalls Recommended • Support deep-linking • Use web URLs for app views where possible • Register the app in your Search Console • Allow appropriate URLs in robots.txt • Ensure first click free in the app • Add markup to pages or sitemaps • Use app indexing API to: ◦ Index personal user content ◦ Add meta information to app views ◦ Enable activities such as voice actions ◦ Expose popularity of app views to Google Checklist for Android app indexing
105. Watch this space Avoid pitfalls Must-have • Support Universal Links ◦ Add your domain(s) to associated-domains in app ◦ Add URLs handled by the app to apple-app-site-association on domain • Use web URLs for app views where possible • Add GoogleAppIndexing registration to your app • Ensure first click free in the app • Enable the back button • Watch out for Google announcing an iOS app indexing API ◦ Enables indexing of personal content ◦ Allows usage information to be sent to Google ◦ Adds meta information Checklist for iOS app indexing (Google)
106. Must-have Recommended • Support Universal Links ◦ Add your domain(s) to associated-domains in app ◦ Add URLs handled by the app to apple-app-site-association on domain • Use web URLs for app views where possible • Add markup to web pages and / or use NSUserActivity API • Use CoreSpotlight API to index personal user content • Use NSUserActivity to: ◦ Add meta information to app views ◦ Expose the popularity of app views to Apple ▪ Designate public or private as appropriate • Add Smart App Banners to your website • Avoid interstitials in the app Checklist for iOS app indexing (Apple)
107. How to perform app audits We have a blog post coming. In the meantime, figure it out from this post
108. Bored of mobile now?
109. Strategy: optimize for what would happen if you ranked 3
110. Anyone remember this chart?
111. How about now? Moz 2009 ranking factors
112. In 2009 I was pumped to be surveyed
113. (I’m British so it was more like)
114. I was pumped because: (a) yay, validation (b) I knew the answers I could be useful
115. More recently, it got hard
116. Which has a bigger effect on rankings? “Uniqueness of content across the whole site” or “Use of responsive design”
117. Too often, the answer was “it depends”
118. That’s the bad news
119. The good news is this is less and less true Feb 2012
120. As a result of all the machine learning
121. Optimize for what would happen if you did rank Do I click? Do I like what I see? Do I get what I want?
122. It’s possible Google is testing your site directly by dropping it into SERPs #1 #2 #3 #4 #5 #1 #2 Your site #4 #5 A B Which SERP makes users happier?
123. But even if it’s not that direct, these are the user signals that Google is optimizing for
124. LET’S TALK TACTICS
126. Use techniques from CRO
129. You can mock up SERPs and do your own split-testing on snippets #1 #2 #3 #4 #5 #1 #2 Your site #4 #5 A B Which gets more clicks?
130. Or apply lessons from PPC
131. Hunt down “short clicks” - see Justin Cutroni’s post
132. Figure out how to track “intent complete” for as many intents as you can
133. Use Qualaroo for “intent research”
134. There are some pitfalls
135. Google’s proxies for “quality” aren’t perfect e.g. duplicated content can be a great user experience
136. Strategy: use testing to figure out what Google wants from your site 4
137. Check out this post from Pinterest’s engineering blog about building an experimental SEO framework
138. They found winners
139. And avoided bad ideas
140. Previously this might have found exploits or loopholes Like keyword repetition or hiding = better rankings
141. Now we are using Google as an oracle It really doesn’t matter if we’re pleasing algorithms designed to please people or pleasing people directly
142. LET’S TALK TACTICS
144. Correlation doesn’t imply causation? Further reading for those interested: • Predicting the present with Bayesian structural time series [PDF] • Inferring causal impact using Bayesian structural time series [PDF] • CausalImpact R package • Finding the ROI of title tag changes
145. Consider typical traffic data
146. Read Ben Estes’ blog post for more We can extract:
147. Read Ben Estes' blog post for more Seasonality... We can extract:
148. Read Ben Estes’ blog post for more ...and trend We can extract:
149. Then we can make forecasts (Dotted line = forecast, blue area = confidence interval)
150. We can detect anomalies We use this on our client-only ops platform to spot unexpected changes
151. Forecast is correct Beats the forecast
152. It’s not all roses
153. It’s hard to make these kinds of changes:
154. And we haven’t worked out how to test internal linking Where the effect propagates throughout the site
155. But it is powerful
156. Optimize for actual Google preferences (rather than guessing how Google will interpret user preferences) 1
157. Avoid wide scale losses from unsuccessful tests 2
158. 1. Desktop is the poor relation to mobile 2. Understand app search 3. Optimize for what would happen if you ranked 4. Test to figure out what Google wants from your site Round-up
159. Oh, and one more thing
160. It is possible to test changes with a proxy
161. And we’ve built one We have an early private beta of a product to do SEO split testing. Come see me afterwards if you are interested
162. Speak to TA for a demo @TomAnthonySEO tom.anthony@distilled.net
163. Speaker photo goes here WILL CRITCHLOW CEO and Co-Founder, Distilled will.critchlow@distilled.net @willcritchlow