Does the URL structure of your AMP pages really impact your SEO?

Why does Google take this specific position?

For years, the SEO community has debated the optimal location for AMP pages. Subdomain (amp.example.com) or subdirectory (example.com/amp/)? This question arose systematically during technical implementations.

Mueller clarifies here that Google treats these two structures equally in terms of ranking. No bonus for subdirectories, no penalty for subdomains. The engine recognizes the relationship between the canonical page and its AMP version regardless of the chosen structure, as long as the rel="amphtml" and rel="canonical" tags are correctly implemented.

What does 'maintaining a stable structure' actually mean?

Mueller's real recommendation is hidden in the second part: architectural stability. Migrating your AMP pages from a subdomain to a subdirectory (or vice versa) triggers the same issues as a standard migration.

You will need to manage 301 redirects, update canonical tags, and endure a waiting period during which Google recrawls and reindexes the new URLs. For a site with thousands of pages, this is a significant undertaking that can temporarily affect the visibility of featured snippets and other rich results associated with AMP.

In what context does this statement make sense?

This position is set in a time when AMP was gradually losing its status as a ranking factor for mobile results. Google decoupled the display in the Top Stories carousel from the AMP requirement, making the format less strategic than before.

By freeing technical teams from this location constraint, Mueller implicitly acknowledges that the issue no longer lies there. What matters is real speed (Core Web Vitals), mobile experience, and consistency of signals between versions of the same page.

• Subdomain and subdirectory: equivalent SEO impact according to Google
• Canonical tags: correctly implemented, they ensure recognition of the AMP/HTML relationship
• Architectural stability: top priority — avoid unnecessary migrations
• Evolving context: AMP is no longer a priority ranking factor for mobile results
• Redirects: any change in structure requires rigorous management of 301s

Does this statement align with real-world observations?

Yes, and it is indeed one of the few positions from Mueller that perfectly aligns with what is observed in production. AMP sites hosted on a subdomain show no measurable disadvantage in terms of rankings or organic traffic compared to those using a subdirectory.

Let's be honest: the real difference lies elsewhere. A subdomain complicates analytics metric consolidation, fragments server log reading, and can cause issues with user session transfer between versions. But from Google's perspective? Nothing to report. [To verify]: some third-party SEO tools (SEMrush, Ahrefs) sometimes treat subdomains as separate entities, which can skew competitive analysis — but that has nothing to do with Google.

What nuances should be added to this position?

Mueller speaks of no SEO impact, but he omits one point: user perception and trust. An URL in amp.example.com may seem less legitimate than an URL example.com/amp/ to some users, especially in sensitive sectors (finance, health).

And that’s where the issue arises — because if user trust declines, the bounce rate increases, the visit duration decreases, and these behavioral signals can indirectly affect rankings. Google won't measure "subdomain = bad SEO", but "this page doesn't retain attention = poor experience".

In what cases does this rule not really apply?

If you manage a multi-site network or a distributed architecture (like CDN with dedicated domains), the question of AMP structure becomes secondary compared to broader infrastructure concerns. In these setups, an AMP subdomain may be imposed by technical deployment constraints.

Another exception: sites that already have a subdomain architecture for other features (blog.example.com, shop.example.com). Adding amp.example.com in this context remains consistent. However, if your main site is monolithic and you create a subdomain solely for AMP, you are unnecessarily complicating your stack without measurable benefit.

What should you do if you already have an AMP structure in place?

Don't change anything — unless you have a major strategic reason. Stability is better than a technical migration without demonstrable benefit. If your AMP pages are on a subdomain and functioning correctly (indexing, canonicals, analytics), migrating to a subdirectory will cost you development resources, risks of breakage, and reindexing time for no SEO gain… at all.

Focus instead on the quality of the implementation: AMP validation without errors, optimal loading times, smooth user experience across versions. This is where the real performance lever lies, not in the URL.

What mistakes should you avoid when initially choosing an AMP structure?

If you are starting an AMP implementation today (which deserves reflection, we’ll come back to that), avoid inconsistent hybrid structures. Some sites mix subdomains and subdirectories according to sections — a maintenance nightmare.

Another classic pitfall: creating an AMP subdomain without properly configuring Search Console. The result: you lose visibility on crawl errors, security signals, and performance data specific to that part of your site. A subdomain = a dedicated Search Console property (or at least, a domain property for consolidation).

How can you check if your current configuration is optimal?

Start with a simple audit: list all your indexed AMP pages (via site:amp.yourdomain.com or site:yourdomain.com/amp/), and check that each page has its canonical tag pointing to the HTML version and vice versa. Use the official AMP validator to identify structural errors.

Next, analyze the Core Web Vitals specific to AMP pages in Search Console. If your AMP pages are not significantly outperforming your standard pages in terms of LCP, FID, and CLS, you might want to abandon AMP in favor of a deep optimization of your standard pages — which are much more sustainable.

• Consistency audit: check that all your AMP pages follow the same structure (subdomain OR subdirectory, never both)
• Canonical tags: test a representative sample to confirm proper bidirectional implementation
• Search Console: set up a dedicated property if you're using a subdomain, and monitor specific AMP errors
• Real performance: compare Core Web Vitals of your AMP pages vs. standard pages — if the gap is marginal, AMP is no longer very useful
• Analytics: ensure that user tracking works correctly across versions to measure true business impact
• Migration plan: if you absolutely must change structure, document a plan with redirects, tests, and possible rollback