Is AMP architecture really as flexible as a separate mobile site?

Does AMP really impose a technical architecture?

No, and this is probably one of the most misunderstood points about this technology. AMP does not dictate any mandatory file structure on your server. You can organize your AMP pages in a dedicated subdomain, a /amp/ subdirectory, or even directly integrate them into your main hierarchy.

This flexibility resembles that of separate mobile sites (m.example.com), where the only technical constraint was the consistency of canonical URLs and redirects. Google treats AMP as a presentation variant, not as an imposed architecture. The structure depends on your technical resources, CMS, and editorial strategy.

What is the difference between AMP and a traditional mobile site in terms of structure?

No fundamental difference in terms of freedom of file organization. Both approaches allow you to choose the location of resources freely. The distinction lies in code constraints: AMP imposes restrictions on JavaScript and CSS styles but not on site topology.

From a crawling perspective, Googlebot treats an AMP hierarchy exactly like any other section of a site. It follows internal links, respects the allocated crawl budget, and analyzes click depth from the homepage. The algorithm does not particularly favor AMP in this regard.

Do navigation links change anything in the equation?

Navigation links in an AMP architecture follow the same SEO rules as traditional navigation. Internal linking remains crucial for distributing PageRank and discoverability of deep pages. If you segment your AMP content into a subdirectory, ensure that your main menu or footer points to this section.

Google clarifies this flexibility because too many SEOs mistakenly believe that AMP requires a specific architecture. In reality, the only real obligation concerns the link tag rel="amphtml" from the desktop version to the AMP version, and vice versa with rel="canonical". The rest is up to your implementation choices.

• AMP imposes no predefined server hierarchy: you structure your files as you wish
• This flexibility resembles separate mobile sites (m.domain.com vs domain.com/mobile/)
• Crawling and internal linking adhere to standard SEO rules, without special treatment
• The only technical constraint: appropriately configured link tags rel="amphtml" and rel="canonical"
• The consistency of navigation between desktop and AMP versions remains a quality factor for user experience

Does this statement align with real-world observations?

Yes, and it is confirmed by years of testing on editorial sites. The most successful AMP implementations use varied structures: some media opted for a subdomain amp.lemonde.fr, others for a /amp/ suffix after each URL, and still others for a complete mirror architecture. None has demonstrated any intrinsic SEO advantage tied to its architectural choice.

What truly matters is load speed, the validity of AMP code, and semantic consistency between versions. A poorly structured site with inconsistent AMP URLs will struggle with issues like content cannibalization or diluted crawl budget, but not because of AMP itself. It's a classic web architecture problem.

What nuances should be added to this statement?

Google remains vague on one point: performance implications based on architectural choice. An AMP subdomain requires an additional DNS lookup, which can add 20-50ms of latency. An /amp/ subdirectory shares the same root domain, benefiting from DNS prefetch. [To be verified] whether this micro-optimization truly influences ranking, but theoretically, every millisecond counts for Core Web Vitals.

Another gray area: the impact on internal linking. If you isolate your AMP pages in a separate branch without links from your main hierarchy, you create a poorly connected content island. Google says it’s flexible but does not specify that this flexibility can backfire if poorly implemented.

When does this rule not really apply?

On complex e-commerce sites, AMP's architectural flexibility quickly runs into practical limits. Product pages with dynamic filters, persistent cart, or user personalization require advanced JavaScript that AMP restricts. In these cases, forcing a "flexible" AMP architecture sacrifices essential features.

Similarly, on single-page web applications (SPAs), AMP integration becomes an architectural nightmare. You end up maintaining two parallel tech stacks, with exponential technical debt. The "flexibility" touted by Google masks the real maintenance costs for non-editorial projects. Let's be honest: AMP is primarily designed for content sites, not transactional platforms.

How do you choose your AMP architecture in practice?

Start by assessing the proportion of mobile traffic on your site. If 70% or more of your visitors come from mobile and your content is primarily editorial, AMP in a /amp/ subdirectory often represents the best compromise. You share the root domain, facilitate crawling, and simplify SSL certificate management.

For a multilingual or multi-region site, prefer a mirror structure that replicates your main hierarchy: example.com/fr/article-123/ becomes example.com/fr/article-123/amp/. This approach maintains semantic consistency and facilitates hreflang management. Avoid AMP subdomains on international sites, as you unnecessarily complicate DNS configuration and certificates.

What mistakes should you avoid in AMP structuring?

Never create an orphan AMP hierarchy without links from your main site. Googlebot must be able to discover your AMP pages naturally through internal linking, not solely via the amphtml tag. If your main menu doesn’t point anywhere to /amp/, you lose part of your SEO juice.

Another classic pitfall: forgetting to configure 301 redirects when migrating from one AMP architecture to another. I've seen sites lose 40% of organic traffic when switching from a subdomain amp.site.com to site.com/amp/ without a redirect plan. Google reindexes, but slowly, and you lose months of visibility in the meantime.

How can you verify that your AMP structure is optimal?

Use Google Search Console to check that your AMP pages are properly indexed and linked to their canonical versions. If you see indexed duplicates or AMP validation errors, it means your structure is creating confusion. Crawl your site with Screaming Frog in "AMP detection" mode to identify pages missing the amphtml tag or with misconfigured canonicals.

Also test the click depth from the homepage to your AMP pages. If some require 5 or more clicks to be reached, your architecture dilutes their authority. Link them more directly through your menu, footer, or associated content blocks. The flexibility of AMP does not exempt you from the fundamentals of SEO architecture.

• Choose a structure consistent with your mobile traffic and content type (editorial vs transactional)
• Correctly configure link tags rel="amphtml" and rel="canonical" on 100% of page pairs
• Maintain strong internal linking between desktop and AMP versions, avoiding isolated islands
• Check in Search Console the indexing and validation of your AMP pages every month
• Measure the click depth to your AMP content: ideally a maximum of 3 clicks from the homepage
• Plan 301 redirects in case of architectural redesign for AMP to avoid traffic loss