Will Rich Cards require HTTPS to appear in Google's results?

Why is Google discussing HTTPS for Rich Cards now?

Rich Cards display enhanced content directly in the SERPs: recipes, product reviews, events. These formats capture attention and drive qualified traffic. The problem? If structured data is transmitted over HTTP, a third party can intercept or modify it along the way.

Google established HTTPS as a ranking signal in 2014 and later pushed Chrome to flag unsecured sites. Mueller's statement aligns with this logic: if Rich Cards require HTTPS in the future, it will be consistent with Google's security roadmap.

What does this actually change for a site on HTTP?

Today, a site on HTTP can still generate Rich Cards if its schema.org markup is correct. But if Google shifts to a HTTPS requirement, these enhancements could disappear overnight. No warning, no grace period: just a drop in CTR and traffic.

The risk is twofold: immediate loss of visibility and a negative signal sent to users. A site without a padlock in 2025 looks suspicious. Modern browsers display red alerts, and users bounce before the page even loads.

Does this HTTPS requirement apply to all types of Rich Cards?

Mueller's statement remains vague regarding the exact scope. We can assume that Rich Cards related to transactions (products, paid events) will be prioritized. Google cannot afford for a price to be altered in transit or for an event date to be changed by a malicious actor.

Recipes, blog articles, or purely informational content may receive a reprieve. But relying on that is betting on Google's mercy. It’s best to secure the entire domain and sleep soundly.

• Rich Cards still function on HTTP, but this tolerance is fragile and likely temporary.
• HTTPS protects the integrity of structured data and enhances user trust, two elements valued by Google.
• No official timeline has been provided, meaning the switch can happen without warning.
• Transactional sites (e-commerce, bookings) will likely be the first affected if Google enforces HTTPS for Rich Cards.
• Shifting to HTTPS remains a technical project: 301 redirects, updating internal resources, monitoring mixed content.

Is this statement consistent with observed practices in the field?

Absolutely. Google has been advocating for HTTPS for years, and the signals are piling up: Chrome labels HTTP sites as “not secure,” Progressive Web Apps require HTTPS, and so do Service Workers. Rich Cards are the next logical domino in this chain.

What stands out is the conditional language used by Mueller: “it might be.” This evasive wording is typical of Google when it prepares the ground without wanting to trigger panic. [To be verified]: no published A/B tests confirm that Google is already disabling Rich Cards on HTTP for certain segments. But the absence of evidence is not evidence of absence.

What risks are there in staying on HTTP for Rich Cards today?

The risk is less immediate than strategic. A site on HTTP can still work today, yes. But it accumulates a technical debt that will explode once Google pulls the lever. And on that day, migrating in urgency exposes you to mistakes: broken redirects, mixed content, indexing drop.

Another point: users themselves are wary of HTTP. A site requesting sign-up or payment without a green padlock is a huge psychological barrier. Rich Cards might bring in traffic, but if that traffic bounces due to a lack of trust, you lose on both fronts.

In what cases might this rule not strictly apply?

Google sometimes allows exceptions for intranets, localhost sites, or development environments. But once a domain is public and crawled by Googlebot, these exceptions no longer hold. If your site generates organic traffic, it’s in scope.

There are also cases where transitioning to HTTPS poses legitimate technical constraints: outdated CMS not compatible with SSL, legacy infrastructure, certificate costs (even though Let's Encrypt has made this nearly free). But Google doesn’t concern itself with technical considerations: if HTTPS becomes required, you comply or disappear from enriched SERPs. It’s harsh, but that’s the game.

What should you concretely do if your site is still on HTTP?

First step: obtain an SSL/TLS certificate. Let's Encrypt offers free certificates with automatic renewal, which eliminates budget excuses. Install it on your server, then test HTTPS access before forcing the redirect.

Next, implement permanent 301 redirects from HTTP to HTTPS for every URL. Don’t just redirect at the domain level: each page must point to its HTTPS version. Otherwise, you lose SEO juice and fragment your indexing.

What mistakes to avoid when migrating to HTTPS?

The classic mistake: forgetting to update internal resources. If your images, scripts, or stylesheets still point to absolute HTTP, you're creating mixed content. Browsers block these resources, your site visually breaks, and Google may refuse to display your Rich Cards.

Another pitfall: failing to update the Search Console. Add the HTTPS version as a new property, submit a new sitemap, and monitor indexing errors. Google treats HTTP and HTTPS as two distinct domains: if you don’t notify the change, you risk a temporary deindexing.

How can you check if your Rich Cards remain active after migration?

Use Google's Rich Results Test on your key pages. Check that the schema.org markup is still valid and that no errors arise. Also inspect the URL in the Search Console to confirm that Googlebot accesses the HTTPS version without redirect loops.

Monitor your impressions and CTR in the 30 days following the migration. If your Rich Cards disappear, you'll see it immediately in the performance reports. Compare before/after on the queries where you had enhancements: a sudden drop signals a technical problem to fix urgently.

• Install an SSL/TLS certificate (Let's Encrypt or commercial) and test HTTPS access.
• Set up permanent 301 redirects from all HTTP URLs to HTTPS.
• Update internal links, resources (images, CSS, JS), and canonical tags to point to HTTPS.
• Add the HTTPS version to the Search Console and submit a new XML sitemap.
• Test your pages with Google’s Rich Results Test to validate the schema.org markup.
• Monitor performance reports (impressions, CTR, indexing errors) for 30 days post-migration.