SEO Amp

I'd start by auditing every AMP page on your site. Pull a list from Google Search Console and run each URL through the AMP Test Tool. I've seen sites where 30% of AMP pages throw validation errors that go unnoticed for months. Those errors mean the AMP version is not being served, so the effort is wasted. Fix the errors or remove the AMP version entirely. My rule: if a page has more than three validation errors, I delete the AMP version and let the canonical page stand alone. Next, check the canonical links. Every AMP page must point to its canonical non-AMP version. If that link is missing or wrong, Google might treat the AMP page as the primary version, which can cause [duplicate content](/duplicate-content/) issues. I've had to clean up a mess where AMP pages were indexed without [canonical tags](/canonical-tags/), and the canonical pages were dropped from the index. Once you're clean, decide whether AMP is worth maintaining. For news sites or template-heavy pages where you cannot easily slim down the front-end code, AMP provides a reliable path to fast load times. I've measured 40% faster load times on AMP for a news article template compared to the standard page. But for custom sites where you control the code, I would drop AMP and invest in a performance optimisation project using lazy loading, efficient CSS, and server-side rendering. That gives you more flexibility and avoids the constraint of AMP's limited JavaScript. The payoff is simpler development and no risk of AMP-specific bugs. If you stick with AMP, keep structured data consistent between versions. That means the same schema markup on both AMP and canonical pages. I've seen AMP pages lose rich results because the structured data was missing or different.

The biggest watch-out is that AMP is not a shortcut to better SEO. If your core [technical SEO](/technical-seo/) is broken, AMP won't fix it. I've advised clients who thought AMP would solve their indexing problems, but they had no sitemap and poor internal linking. AMP only affects the page's speed and stability; it doesn't help with crawlability or content quality. Another watch-out is canonicalisation. If you use AMP, you must have a self-referencing canonical on the AMP page and a link to the AMP version from the canonical page. I've seen sites that had the AMP page linking to the canonical but not vice versa, which caused Google to treat the AMP page as the canonical. That's a disaster if the AMP page omits important content or interactive elements. Structured data is another trap. Google recommends keeping schema markup identical on both versions. I've seen sites that put structured data only on the canonical page, losing rich results on AMP. Or worse, they put different structured data on AMP, confusing Google. Also, AMP's validation can be brittle. A single custom tag or inline style that violates the AMP specification will invalidate the entire page. I've had to remove third-party scripts that worked fine on standard pages but broke AMP validation. The AMP Test Tool is your friend here, but you need to check regularly because changes to the canonical page might break the AMP version. Finally, consider the maintenance cost. Every time you update your canonical page, you must update the AMP version too. If you have a large site, that's a lot of overhead. I've seen teams abandon AMP after a year because the manual sync was too burdensome. For many sites, a standard performance optimisation approach with good caching and a lightweight theme is more sustainable and gives you more control.

I used to believe that AMP was essential for ranking well in [mobile SEO](/mobile-seo/). I bought into the narrative that Google would favour AMP pages in the mobile index. I was wrong. Google has stated clearly that AMP is not a ranking factor. What matters is page experience, which AMP helps with, but so do many other techniques. I wasted time converting pages to AMP when I could have been fixing slow server response times or optimising images. Another mistake: I underestimated the complexity of implementing AMP on a site with custom JavaScript. I assumed that AMP's restrictions would be a feature, but they became a constraint. I had to rewrite interactive elements, and in some cases, the AMP version was a stripped-down experience that performed worse in user engagement. Users spent less time on AMP pages because they offered less functionality. I should have done A/B testing before rolling out AMP across the entire site. I also got canonicalisation wrong early on. I set the AMP page's canonical to the non-AMP page, but I forgot to add a link from the non-AMP page to the AMP version. That caused Google to treat the AMP page as the canonical, and the non-AMP page lost its indexed status. It took weeks to recover. Lastly, I once told a client that AMP would automatically improve their [Core Web Vitals](/core-web-vitals/) scores. It didn't. The AMP page did load faster, but the LCP and CLS scores were still poor because of large images and dynamic content that AMP couldn't optimise. I now know that AMP is just one tool, not a silver bullet. If I could go back, I would prioritise a comprehensive performance audit over AMP adoption.