Google announced last night that they are working up a solution to show the publishers URL and not the Google AMP cache URL from google.com/amp in Google search. Google wrote "we are making changes to how AMP works in platforms such as Google Search that will enable linked pages to appear under publishers’ URLs instead of the google.com/amp URL space while maintaining the performance and privacy benefits of AMP Cache serving."
I love how Malte Ubl, the Tech Lead for the AMP Project at Google, put it on Twitter:
💥 You don't like https://t.co/tpOl8FTL7v URLs? Neither do we👊
— Malte Ubl (@cramforce) January 9, 2018
And so we are making the changes to no longer need them while retaining the performance & privacy benefits of AMP.
Read this post for details & thanks so much for all the feedback! ❤️https://t.co/qdJmVfpSm5
Michelle Robbins summed it up well on Search Engine Land that this is a long standing issue publishers have had with AMP - that the URL is often off of Google's own URL framework to properly serve the AMP cache. In fact, Google has tried multiple solutions or hacks to get publishers URLs in the search results including a way to show the publisher URL and share that URL over the AMP cache URL on Google's server.
Well now, Google is working with the W3C to serve the publishers URL instead of the AMP cache URL, Google explained:
We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG, we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard. Based on this web standard AMP navigations from Google Search can take advantage of privacy-preserving preloading and the performance of Google’s servers, while URLs remain as the publisher intended and the primary security context of the web, the origin, remains intact. We have built a prototype based on the Chrome Browser and an experimental version of Google Search to make sure it actually does deliver on both the desired UX and performance in real use cases. This step gives us confidence that we have a promising solution to this hard problem and that it will soon become the way that users will encounter AMP content on the web.The next steps are moving towards fully implementing the new web standard in web browsers and in the Google AMP Cache. Our goal is that Web Packaging becomes available in as many browsers as possible (after all Web Packaging has exciting use cases beyond just AMP such as offline pages, ES6 module loading, and resource bundling). In particular, we intend to extend existing work on WebKit to include the implementation of Web Packaging and the Google Chrome team’s implementation is getting started.
This won't be released until the second half of this year but this is exciting news to publishers and webmasters who are using AMP or thinking of using AMP.
Forum discussion at Twitter and WebmasterWorld.
