HTTPS and site security: migration, mixed content, HSTS and hacked sites

Why HTTPS matters for search

Google does not describe HTTPS as a big ranking lever, and you should not either. What Google does say is concrete. Its page experience self-assessment asks: “Are your pages served in a secure fashion?” Google's web.dev guide on enabling HTTPS states: “Google uses HTTPS as a positive search quality indicator.” And the Search Console Help for the HTTPS report puts it plainly: “Google strongly recommends using HTTPS for your site to protect your users' security and privacy.”

Keep this in proportion. On the same page experience page, Google writes that “Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results.” It adds that “they can make your website more satisfying to use, which is generally aligned with what our ranking systems seek to reward.” HTTPS will not lift a weak page above a stronger one. Its effect on search is more practical:

• Canonical choice. When the same page exists on http:// and https://, Google normally picks the HTTPS URL, unless something on your site contradicts it.
• Users and browsers. Browsers mark HTTP pages as not secure, which is especially off-putting on forms, logins and checkouts.
• Referrer data. Browsers do not pass the referrer from an HTTPS page to an HTTP page. If your site is still on HTTP, visits from HTTPS sites can appear in analytics as direct traffic.
• Modern features. Many browser features, such as service workers and HTTP/2 in browsers, work only over HTTPS.

What Google officially says

The four exceptions Google lists, word for word:

• “The HTTPS page has an invalid SSL certificate.”
• “The HTTPS page contains insecure dependencies (other than images).”
• “The HTTPS page redirects users to or through an HTTP page.”
• “The HTTPS page has a rel="canonical" link to the HTTP page.”

To make sure Google picks HTTPS, the same page recommends: “Add redirects from the HTTP page to the HTTPS page.” “Add a rel="canonical" link from the HTTP page to the HTTPS page.” “Implement HSTS.”

Two more rules from that page: “Don't include the HTTP version of your pages in your sitemap or hreflang annotations rather than the HTTPS version.” And: “Avoid implementing your SSL/TLS certificate for the wrong host-variant. For example, example.com serving the certificate for subdomain.example.com.”

Certificate basics

HTTPS is HTTP over TLS. The server presents a certificate issued by a certificate authority (CA). The browser checks that the certificate is valid, not expired, issued by a trusted CA and issued for the exact hostname it is visiting. If any of these checks fails, the visitor sees a full-page warning and Search Console reports “HTTPS has invalid certificate”, which Google says “Typically this affects an entire site.”

• Type does not matter for SEO. A free, automatically renewed domain-validated certificate (for example from Let's Encrypt) works the same in search as a paid OV or EV certificate.
• Cover every host you serve. If you serve example.com and www.example.com, the certificate must include both names, even if one of them only redirects. A redirect from https://www.example.com cannot run until the TLS handshake succeeds.
• Wildcards cover one level. web.dev notes: “In wildcard certificates, the wildcard applies to only one DNS label.” *.example.com covers shop.example.com but not eu.shop.example.com, and not example.com itself.
• Send the full chain. The server must send the intermediate certificates too. A missing intermediate often works in one desktop browser and fails on mobile devices and in crawlers.
• Automate renewal and monitor expiry. An expired certificate breaks the whole site at once. Set up auto-renewal and a separate alert a few weeks before the expiry date, in case renewal silently fails.

HTTP to HTTPS migration step by step

Google treats a switch to HTTPS as a site move with URL changes: its site move guide lists “URL changes from HTTP to HTTPS” as the first example. The URLs change only in the protocol, so the move is simple, but every signal still has to switch together.

1. Get the certificate. Google's site move guide: “For a move to HTTPS, get and configure the required TLS certificates on your server.” Include every hostname you serve.
2. Serve the site on HTTPS without redirecting yet. Test every template: home, category, product, article, search, forms, checkout, login.
3. Switch internal links and resources. Use https:// or root-relative paths (/img/logo.png) in templates, menus, content, CSS files and JavaScript. In a CMS, replace old absolute http://example.com URLs in the database with a tested script, not by hand.
4. Switch canonicals to HTTPS. Every page's rel="canonical" should point to its own HTTPS URL. A leftover HTTP canonical is one of Google's listed exceptions.
5. Switch sitemaps and hreflang. List only HTTPS URLs in the sitemap; all hreflang annotations should use HTTPS URLs.
6. Update everything else that holds URLs: structured data, Open Graph tags, feeds, CDN and cache rules, analytics and ad settings, email templates, and app deep links.
7. Turn on 301 redirects. Every HTTP URL redirects to the same path and query on HTTPS, in one hop. Combine it with your host choice: http://www.example.com/a?x=1 goes straight to https://example.com/a?x=1, not via https://www.example.com/a?x=1.
8. Check robots.txt on HTTPS. https://example.com/robots.txt is the file that now counts. Make sure it does not block what the HTTP one allowed.
9. Set up Search Console. A Domain property covers both protocols and all subdomains. If you use URL-prefix properties, add the HTTPS one. Submit the HTTPS sitemap there.
10. Skip Change of Address. Google: “You don't need it for HTTP to HTTPS moves, switching between www and non-www on the same domain, or moving paths within the same domain.”
11. Monitor. Use the HTTPS report, Page indexing, Crawl stats and Performance reports, plus a crawl of the HTTP URL list to confirm each one returns a single 301 to a 200 page.
12. Keep the redirects. Google advises: “Keep the redirects for as long as possible, generally at least 1 year.” For HTTP to HTTPS there is rarely a reason to ever remove them.
13. Add HSTS last, once everything above is stable (see below).

A minimal nginx setup that sends every HTTP request, and the www host, to one HTTPS host in a single hop:

# HTTP, both hosts: one hop to the final HTTPS URL
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
# HTTPS www: needs a valid certificate for www too
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

In Search Console's HTTPS report, the errors that matter most during a migration are “HTTP marked with canonical tag”, “HTTPS has invalid certificate”, “Sitemap points to HTTP”, “HTTPS has redirect” (the HTTPS URL redirects to HTTP), “HTTPS URL is roboted” and “HTTPS not evaluated”. Fix them early: Google warns that “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” The report is “available only for Domain properties and HTTPS URL-prefix properties.”

Mixed content

web.dev defines it: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” It weakens the whole page, because those HTTP requests can be read and changed on the network.

“There are two types of mixed content: active and passive.”

• Passive (images, video, audio): it “doesn't interact with the rest of the page”. Browsers may upgrade it to HTTPS automatically; if no HTTPS version exists, it does not load. The address bar can still show the page as not secure.
• Active (scripts, stylesheets, iframes, anything the browser executes): it “interacts with the page as a whole”. Browsers block it by default, so the page can lose its styles, menus, forms or tracking.

For search this matters twice. Google's canonical rules name “insecure dependencies (other than images)” as a reason it may not prefer the HTTPS page. And when blocked scripts or styles break rendering, Google may see a different page from the one you designed.

<!-- page: https://example.com/shop/ -->
<link rel="stylesheet"
  href="http://example.com/css/main.css">
<script
  src="http://cdn.example.com/app.js"></script>
<img
  src="http://example.com/img/logo.png">
<iframe
  src="http://maps.example.com/embed"></iframe>

<!-- page: https://example.com/shop/ -->
<link rel="stylesheet"
  href="/css/main.css">
<script
  src="https://cdn.example.com/app.js"></script>
<img
  src="/img/logo.png">
<iframe
  src="https://maps.example.com/embed"></iframe>

How to find mixed content

1. DevTools. Open key templates over HTTPS and check the Issues tab and the console. Messages only cover the page you are on, so this works for templates, not for a whole site.
2. Search the source. web.dev's advice: “Search for http:// in your source and look for tags that include HTTP URL attributes.” Include the database, theme files, CSS (url(http://…), @import, fonts) and JavaScript.
3. Crawl. A crawler that records the resources of each HTML page lists every HTTP image, script and stylesheet across the site.
4. Collect browser reports. Send a Content-Security-Policy-Report-Only header; real visitors' browsers then report every insecure request without blocking anything.

How to fix it

Change each http:// resource to https:// or to a relative path. If a third party does not offer HTTPS, host the file yourself (if you are allowed to), use another provider or remove it. As a safety net, not a replacement for fixing the source, you can send:

Content-Security-Policy: upgrade-insecure-requests

The browser then requests HTTPS versions of HTTP resources. If a resource has no HTTPS version, it simply fails to load.

HSTS and preload

HTTP Strict Transport Security tells the browser: for this host, use HTTPS only, for the next max-age seconds. After the first HTTPS visit, the browser rewrites any http:// link to https:// before sending a request. That removes the redirect round trip for repeat visitors and protects against downgrade attacks.

# start low while testing
Strict-Transport-Security: max-age=300
# then, once stable
Strict-Transport-Security: max-age=31536000; includeSubDomains

The catch is that HSTS gives visitors no way to click past a certificate error. web.dev warns: “Don't enable HSTS until you're certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” If a certificate expires while HSTS is active, returning visitors cannot get in at all until you fix it. Hence the second piece of advice: “You can start with low values and gradually increase the max-age as you become more comfortable operating an HTTPS-only site.”

• Send it only over HTTPS, on the final host. Browsers ignore it over HTTP.
• includeSubDomains applies the rule to every subdomain, including old ones you may have forgotten: an intranet tool, a staging host, a mail web client. Add it only when every subdomain works on HTTPS.
• Preload means asking for your domain to be built into browsers' HSTS lists, so even the very first visit uses HTTPS. It requires includeSubDomains, a long max-age and the preload directive. Getting off the list takes a long time, so treat preloading as close to permanent and do it last, if at all.
• HSTS does not fix bad signals. Google is explicit that HSTS “cannot override” the HTTP preference caused by bad certificates and HTTPS-to-HTTP redirects. Fix those first.

Other security headers

These headers are good practice for protecting users and the site. They are not ranking factors, and you do not need them for Google to index you, but they make several common attacks much harder.

How hacking hurts search

Google's spam policies define the problem: “Hacked content is any content placed on a site without permission, due to vulnerabilities in a site's security.” Most hacks on ordinary sites are not personal. Bots scan for outdated software and weak passwords, then use the site's reputation to rank spam, spread malware or host phishing pages. The owner often sees nothing, because “If a site is hacked, it's not uncommon for the hacker to use cloaking to make the hack harder for the site owner to detect.”

The damage in search comes in several forms. Google's Security issues help says that affected pages “can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them”, and that “Google tries its best to keep hacked content out of our search results.” Spam aimed at search can also lead to a manual action, and thousands of injected pages compete for crawling with your real content.

Security Issues and Manual Actions reports

The Security issues report is where Google tells you what it found: “If a Google evaluation determines that your site was hacked, or that it exhibits behavior that could potentially harm a visitor or their computer, the Security issues report will show Google's findings.” Issues fall into three groups: hacked content, malware and unwanted software, and social engineering. Expand an issue to see the date it was first detected and sample URLs. The samples are “not necessarily complete”, and an issue with no samples does not mean no pages are affected.

If you cannot reproduce a warning, trust the report rather than your own browser: Google says you “should rely on the Security Issues report as the source of truth to verify whether any security issues exist for your site, or if they have been fixed.” One issue is softer than the rest. For “Uncommon downloads”, Google notes that it “will not prevent your page or site from appearing in Google Search results”, although Chrome may warn about the file.

The Manual actions report covers a different kind of problem. Google explains the difference:

The consequence is spelled out in the Manual actions help: “If a site has a manual action, some or all of that site will not be shown in Google search results.” A hack can show up in both reports: malware and phishing in Security issues, mass spam pages or abused user content as a manual action such as “Site abused with third-party spam”. Check both, and make sure you get Search Console messages by email.

Bought a domain with a history? Google covers it: fix the issues, then say in your reconsideration request “that you recently acquired the site and that it now adheres to the spam policies for Google web search.”

Cleaning up a hacked site and requesting review

1. Confirm the issue safely. Google advises: “Avoid using a browser to directly view infected pages on your site.” Use URL Inspection to see the page as Google sees it, and curl to imitate a visitor arriving from Google, because “Hackers often attack only specific user-agents or referrers to avoid detection and select better targets”:

   curl -sv --referer "https://www.google.com/" \
     -A "Mozilla/5.0 (Linux; Android 14) Mobile" \
     https://example.com/page.html

2. Contain it. Put the site into maintenance mode if visitors are at risk, and take a copy of the hacked files, database and logs before you change anything. You need it to find out how the attacker got in.
3. Check who has access. Look for unknown admin users in the CMS, unknown FTP, SSH or hosting accounts, and unknown owners in Search Console. Remove them.
4. Find all the changes. Search files and the database for code you did not write. Google suggests: “Useful search terms include "search", "eval", "base64_decode", and "unescape".” Compare core files with clean copies, and look for recently modified files, unknown PHP files in upload folders, and edited .htaccess or server config.
5. Find injected URLs. Run site:example.com searches, alone and with spam words such as site:example.com pharmacy. Check Performance for queries unrelated to your business and the Sitemaps report for sitemaps you did not submit.
6. Clean. Google gives two options: “replace affected files with the last good backup” or remove the spam yourself. Make sure the backup predates the hack. Spam URLs you delete should return 404 or 410, not redirect to your home page.
7. Close the entry point. Update the CMS, plugins and themes, remove anything unused, and change every password and key: CMS, database, hosting, SFTP and API keys.
8. Fix everything, everywhere. “Fix the issue throughout your site. Fixing the issue on just some pages will not earn you a partial return to search results.” If several issues are listed, fix all of them.
9. Request a review. In the Security issues report select Request Review and describe what you did. Google says a good request “Explains the exact quality issue on your site”, “Describes the steps you’ve taken to fix the issue” and “Documents the outcome of your efforts.” For a manual action, use Request Review in the Manual actions report.
10. Wait, and do not resubmit. “A review can take from a few days to a few weeks to complete.” Resubmitting too early backfires: “Submitting a reconsideration request when the issue hasn't been fixed can cause longer turnaround time for the next request, or even get you marked as a repeat offender.”

Prevention

Google's prevention guide opens with: “The price of freedom from malware is eternal vigilance.” In practice, most hacks are prevented by a handful of habits:

• Update everything“Stay up-to-date with the latest software updates and patches.” CMS core, plugins, themes, server software.
• Remove what you do not useOld plugins, abandoned blogs and forums, test installs and staging copies left online.
• Lock down accountsUnique passwords, two-factor login, one account per person, minimum rights, and removal when people leave.
• Use secure protocols“Google recommends using SSH and SFTP for data transfer, rather than plain text protocols such as telnet or FTP.”
• Tight permissionsNo world-writable directories; uploads cannot execute scripts; config files outside the web root.
• Backups you can restoreAutomatic, stored off the server, tested, kept long enough to reach back before a hack.
• Watch third partiesAds, widgets, tag managers and scripts from other hosts run with your site's trust.
• MonitorSearch Console messages by email, the Security issues report, periodic site: searches, logs and file-change alerts.

Common mistakes

• ✕Redirect chains during the switchhttp://www → https://www → https:// instead of one hop to the final URL.
• ✕Everything redirected to the home pageEach HTTP URL must go to its own HTTPS equivalent, with path and query.
• ✕HTTP canonicals left in templatesA hard-coded http:// canonical tells Google to prefer HTTP.
• ✕Old sitemaps and hreflangSitemaps, hreflang and structured data still listing http:// URLs.
• ✕Certificate missing a hostThe certificate covers example.com but not www.example.com, so the www redirect fails with a warning.
• ✕Mixed content in CSS and the databaseTemplates fixed, but old posts, fonts and background images still load over HTTP.
• ✕HSTS too earlyA long max-age with includeSubDomains or preload before every host works on HTTPS.
• ✕Partial cleanup after a hackSpam removed from visible pages, but the backdoor, the hacker's admin account or injected pages are left.
• ✕Requesting review too earlyBefore every listed issue is fixed on every page.

FAQ

Sources

• Google Search Central — Understanding page experience in Google Search results
• Google Search Central — How to specify a canonical URL
• Google Search Central — Site moves with URL changes
• Search Console Help — HTTPS report
• web.dev — Enable HTTPS on your servers
• web.dev — What is mixed content?
• web.dev — Fixing mixed content
• Google Search Central — Spam policies (hacked content, cloaking)
• Google Search Central — Preventing and monitoring abuse on your site
• Google Search Central — Preventing malware infection
• Search Console Help — Security issues report
• Search Console Help — Manual actions report

Quotes checked against the official pages on 30 October 2026.