Does Google really require AMP for Web Stories?

Web Stories are the web equivalent of Instagram or Snapchat stories — vertical, immersive visual content designed to be consumed quickly on mobile. Google launched this format to capture the attention of mobile users who prefer to scroll through visual content rather than read long articles.<\/p>\n\n

The format is based on AMP Stories, an extension of the AMP framework. The idea: to provide an ultra-fast, standardized experience that Google can serve directly from its cache. The result? Instant loading, but also strict technical control over the structure and code.<\/p>\n\n

Google requires that every Web Story complies with AMP specifications for three main reasons. First, it enables serving content via the Google AMP cache, which preloads pages and ensures almost zero loading time. Second, it standardizes the format — no more custom scripts that slow down or break the experience. Finally, it filters content: only publishers capable of producing valid AMP code can play.<\/p>\n\n

Specifically, if your Web Story contains an AMP error — a missing attribute, an unauthorized script, an improperly sized image — it will not be eligible to appear in Google results. No second chances, no "it'll go through anyway." Validation is binary.<\/p>\n\n

If you want your Web Stories to appear in Google Search, Discover, or Images, you must follow a strict workflow. Create the story in valid AMP HTML, use authorized components (amp-story, amp-img, amp-video…), test with the AMP validation tool, publish, then submit to Google via Search Console or wait for the crawl.<\/p>\n\n

The problem? AMP imposes heavy technical constraints: no custom JavaScript, limited file size, rigid tag structure, dependence on sometimes buggy or poorly documented AMP components. For a site that is not already using AMP, it's a parallel ecosystem to maintain.<\/p>\n\n

\n
• A Web Story must be a valid AMP document — no errors tolerated, mandatory validation before indexing.<\/li>\n
• The Google AMP cache serves stories to ensure maximum performance — but you lose some control over the code.<\/li>\n
• No custom JavaScript or complex tracking — only authorized AMP components, which limits advanced analytics or programmatic monetization options.<\/li>\n
• Eligibility in Search, Discover, and Images depends on this validation — an AMP error = no visibility on Google.<\/li>\n
• The format is optimized mobile-first — desktop is a second-class citizen, which can be an issue if your audience is predominantly desktop.<\/li>\n<\/ul>

To be honest: Google has largely abandoned AMP as a prerequisite elsewhere. Core Web Vitals have replaced AMP as the ranking criteria for standard articles. The AMP badge has disappeared from the SERPs. The framework is maintained, but it is no longer promoted as a universal solution. However, for Web Stories, AMP remains mandatory.<\/p>\n\n

Why this inconsistency? Because Web Stories are a closed, controlled format that Google wants to standardize 100%. The AMP cache enables Google to serve content directly, without going through your server — thus total control over speed, display, and incidentally consumption data. It's a proprietary ecosystem logic, not an open web one.<\/p>\n\n

The main issue is technical complexity for uncertain gain. Creating a valid AMP Web Story requires either using a third-party tool (Google Web Stories for WordPress, Make Stories…) or coding in native AMP — which involves mastering a framework that few developers still know. Visual tools simplify things but also limit customization and sometimes generate bloated code.<\/p>\n\n

Then, there’s the question of ROI. [To be verified]<\/strong>: Google shares little about the actual traffic generated by Web Stories. Field feedback is mixed — some publishers see a visibility boost in Discover, while others notice high impressions but low CTR and mediocre engagement. It's hard to justify the technical investment if conversions don't follow.<\/p>\n\n