Why is HTTPS mandatory for your embedded AMP content?

What does Google actually mean by "embedded AMP content"?

Google refers to all embedded elements within an AMP page: YouTube or Vimeo videos, audio players, third-party iframes, social widgets, programmatic ads. If a piece of content comes from an external source and displays in your AMP page, it falls under this rule.

AMP enforces a strict security policy: no mixed content. If your page loads over HTTPS but an embed points to an HTTP URL, the browser will block the resource. The component simply does not display.

Why does this technical requirement exist?

The AMP framework was designed with enhanced security constraints to protect mobile users. Google serves AMP pages from its cache (google.com/amp/...), which creates both legal and technical responsibilities for the content being delivered.

Mixed content opens the door to man-in-the-middle attacks: an attacker can intercept an HTTP video and inject malicious code. On mobile, where public networks are common, this risk becomes critical. Google cannot validate AMP pages that compromise their users’ security.

What happens if my embeds remain HTTP?

Modern browsers silently block the loading of non-secure resources within an HTTPS context. Your AMP page will show a blank space where the video or widget should appear. No error message is visible to the average user.

The AMP validators detect these violations and mark the page as invalid. Google cannot index or display in AMP carousels a page that fails validation. You lose the performance and visibility benefits that justify the use of AMP.

• HTTPS mandatory for all third-party embeds: videos, iframes, social widgets, ads
• Browser blocking in case of mixed content, with no display or error message
• AMP validation failure if HTTP resources persist in the code
• Exclusion from Google AMP cache and mobile enriched formats for invalid pages
• Potential mobile SEO impact if your enriched content disappears from search results

Is this requirement consistent with observed practices in the field?

Absolutely. Since Chrome and Firefox block mixed content by default, this AMP rule is just a logical extension of current web standards. Browsers already treat an HTTPS page with HTTP resources as a security flaw.

The real question isn’t whether Google is right to enforce HTTPS, but why some CDNs and video providers are still slow to migrate their old URLs. We still see automatically generated embed codes that point to legacy HTTP domains. This is mainly an issue of poorly maintained third-party tools.

What nuances need to be added to this statement?

Mueller speaks of "transmission security," but the real stakes go beyond that. HTTPS also ensures content integrity: no one can alter the video during transit. For Google, this is crucial when serving your pages from their infrastructure.

However, be cautious: HTTPS alone does not solve everything. An HTTPS embed pointing to a compromised domain or loading malicious scripts remains dangerous. AMP validation checks the protocol, not the legitimacy of the content. [To be verified]: Does Google analyze the reputation of third-party domains in AMP embeds? There’s nothing official on this point.

In what cases does this rule cause practical issues?

Archived content is a classic case. If you integrate videos hosted on a dated internal server without an SSL certificate, you either need to migrate the entire system or re-upload to a modern CDN. This is not always trivial with thousands of legacy videos.

Partner widgets also pose a problem. Some booking tools, calculators, or embedded comparators still do not offer HTTPS versions. You then need to choose: abandon AMP on those pages or remove the widget. Sometimes a painful trade-off for e-commerce sites.

What should you prioritize checking on your AMP pages?

First, audit all amp-iframe and amp-video components in your templates. Look for src= attributes that start with http:// (without the s). A simple grep in your codebase reveals most cases.

Then test using the official AMP validator (validator.ampproject.org) and the Chrome console. Mixed content errors will appear in the Network tab with a status of "blocked:mixed-content". Be aware: some resources may load locally but fail in production depending on your server configuration.

How do you fix non-compliant embeds?

For YouTube, Vimeo, and Dailymotion videos, simply replace http:// with https:// in the embed URLs. These platforms have all supported HTTPS for years. Ensure that the automatically generated iframe is using the secure protocol by default.

For your own media, make sure your CDN or video server has a valid SSL certificate. Let's Encrypt offers free certificates if budget is limited. If you are serving from a dedicated domain (cdn.yoursite.com), don’t forget the certificate for this subdomain as well.

What mistakes should you avoid during migration?

Don’t rely on server 301 redirects from HTTP to HTTPS. AMP validation reads the raw source code: if you write src="http://...", the page is invalid even if the server then redirects to HTTPS. Directly modify the markup.

Avoid relative URLs (src="//example.com/video.mp4") that inherit the page's protocol. While technically functional, they can create validation ambiguities. Always prefer explicit absolute HTTPS URLs in AMP.

• Audit all amp-iframe, amp-video, amp-audio in your AMP templates
• Validate each page with the official AMP tool and browser console
• Systematically replace http:// with https:// in src attributes
• Check that your CDN/video server has an up-to-date SSL certificate
• Test the actual media loading after changes, not just the validation
• Document legacy URLs to avoid regressions during updates