AMP (Accelerated Mobile Pages) technology is becoming a thing of the past, and that’s a good thing

In 2015, Google introduced Accelerated Mobile Pages (AMP) as a solution to slow-loading websites on smartphones. The idea was simple: website owners would create a separate, stripped-down version of their pages using a limited subset of HTML, CSS, and JavaScript. These pages could be cached by Google and delivered much faster than regular web pages.

At first glance, the concept seemed reasonable. However, instead of encouraging developers to optimize their existing websites, AMP introduced an entirely separate ecosystem with its own rules, restrictions, and components. Rather than improving the web itself, it required developers to build and maintain a second version of their content.

For several years, Google heavily promoted AMP. News publishers, in particular, were under significant pressure to adopt the technology because AMP pages were effectively required to appear in the Top Stories carousel on mobile search results. As a result, many websites implemented AMP not because it offered clear benefits, but because they couldn’t afford to lose search traffic.

Eventually, however, Google began distancing itself from its own technology.

In 2021, the company removed the requirement for AMP pages to appear in the Top Stories section. Instead, eligibility became based on overall page quality, including Core Web Vitals. This was a clear signal that fast websites no longer needed AMP to receive prominent placement in Google Search.

Since then, AMP has seen very little meaningful development. Major updates have become increasingly rare, development activity has slowed significantly, and the project’s official social media accounts have remained inactive for years. These are all strong indicators that AMP is no longer a strategic priority for Google.

The biggest problem with AMP has always been the need to maintain two versions of the same website. Developers must create separate templates, test two different versions of every page, keep them synchronized, and fix the same issues twice. This increases development costs, complicates maintenance, and creates more opportunities for bugs and inconsistencies.

On top of that, AMP imposes numerous technical limitations. Many common JavaScript features are either unavailable or require AMP-specific components. As a result, developers often have to redesign features, implement workarounds, or abandon certain functionality altogether.

In many ways, AMP resembles WAP, the technology that powered mobile websites in the early 2000s. Back then, developers created separate WAP versions of websites with simplified layouts and limited functionality because mobile phones simply couldn’t handle full websites.

Once smartphones became powerful enough, WAP quickly disappeared. There was no longer any reason to maintain a separate mobile version when one responsive website could serve every device.

AMP follows a remarkably similar path. Instead of promoting a single, well-optimized website, it encouraged developers to build yet another version of the same content. From today’s perspective, that feels more like a step backward than genuine progress.

Supporters of AMP often claimed it offered SEO advantages. Today, that argument is difficult to defend. Google has repeatedly stated that AMP itself is not a ranking factor. Search visibility depends on page quality, loading performance, usability, and content—not on whether a website uses AMP.

Ultimately, AMP introduced more complexity than value. It increased development and maintenance costs, forced thousands of websites to support duplicate versions of their pages, and delivered benefits that gradually disappeared as both browsers and the web evolved. History has already shown what happens to technologies that rely on maintaining parallel versions of the same website. WAP eventually became obsolete, and AMP appears to be following exactly the same path. For the modern web, that is probably a positive development.