Google announced today that they are well on their way to solving one of the most annoying (to publishers) “features” of AMP (Accelerated Mobile Pages) – Google URLs, not the publisher URLs, displaying in search results served from the AMP cache.
Several half-steps have been taken along the path of the AMP project development to address this problem, but the absence of a full solution that maintains the publisher URL continues to be a factor impeding adoption of the framework. In April of this year, Apple went so far as to push out it’s own solution for iOS/Safari users.
Acknowledging this outstanding issue, Malte Ubl, Tech Lead for the AMP Project at Google, posted on Twitter saying “you don’t like http://google.com/amp URLs? Neither do we.”
This will be welcome news to publishers that have already adopted the AMP framework — and encourage those on the fence that haven’t to edge closer, or finally jump on board.
Malte explained what is happening behind the scenes to make this happen:
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.
Malte expects the first changes to be seen in the second half of 2018. We’ll especially be looking forward to this and will keep our readers posted as it begins to rollout.
For more details, check out the Google blog post.