Moving from HTTP to HTTPS without losing rankings

TL;DR: An HTTPS migration is a site-wide URL change, and search engines treat http://yoursite.com and https://yoursite.com as different URLs. Done properly, rankings transfer with a brief settling period. Done carelessly, you split your site across two protocol versions and lose ground for weeks.

Two steps cause most of the damage. Updating URLs in the database with a plain SQL find-and-replace corrupts serialised settings, which silently wipes widget and theme configuration. And forgetting to add the HTTPS property in Search Console means you lose visibility at the exact moment you need it, because Google treats it as a separate property.

Why this is a migration, not a toggle

Installing a certificate takes a minute. Moving a site to HTTPS is a different exercise, because every URL on the site changes.

Search engines index URLs, and http://example.com/page and https://example.com/page are two distinct URLs pointing at what may be identical content. Without correct handling you end up with both indexed, link equity split between them, and duplicate content signals across your entire site.

Internally, the same split appears. Links in post content, image sources, canonical tags, sitemap entries, hardcoded theme references and plugin settings all carry absolute URLs with the old protocol.

Externally, everything pointing at you — backlinks, analytics properties, Search Console, ad platforms, social profiles, API integrations — references the HTTP version.

None of this is difficult. It is just more than one switch, and the failures come from treating it as one.

The upside is real: HTTPS is a ranking signal, browsers flag HTTP pages as not secure, HTTP/2 and HTTP/3 require it and bring genuine performance gains, and forms submitted over plain HTTP transmit personal data in the clear, which sits badly against any data protection obligation.

Before you start

Take a full backup. Files and database, stored off the server. This migration touches every URL in your database, and a bad find-and-replace is not something you want to fix by hand.

Work on staging first if the site is complex or high-traffic. A store or a site with heavy customisation deserves a rehearsal, and staging makes it cheap.

Inventory your external references. Analytics property, Search Console property, ad platforms, payment gateway callback URLs, API integrations with hardcoded URLs, social profile links, email signature links, and any partner site linking to you. You will update these afterwards.

Note your current rankings and traffic. A baseline from Search Console and analytics, so you can tell later whether the settling period is normal fluctuation or a real problem.

Check for hardcoded URLs in theme files. Search your theme for http://yourdomain.com. Database replacement will not touch these.

Pick a quiet window. Not the day before a campaign, not during a sale.

Step one: install and verify the certificate

Most hosts issue free certificates with automatic renewal, which is the right choice for the vast majority of sites. Our comparison of free versus paid SSL covers when a paid certificate is genuinely justified, which is narrower than the marketing suggests.

After installation, verify properly:

Load the site over HTTPS explicitly by typing the https:// URL. It should load without warnings, though it will likely show mixed content issues at this stage, which the later steps fix.

Check the certificate covers what it needs to. Both example.com and www.example.com if you use both. A certificate covering only one produces a warning on the other.

Check the chain. An incomplete certificate chain works in desktop browsers that cache intermediates and fails on some mobile devices, which is a nasty class of bug because it is invisible from your own machine. Free online SSL testing tools report this in seconds.

Test your TLS configuration, not just the certificate. Obsolete protocol versions disabled, modern cipher suites, TLS 1.3 enabled. The same testing tools grade this.

Do not proceed until HTTPS loads cleanly, because everything after this assumes it works.

Step two: update URLs in the database

The step that breaks sites.

WordPress stores absolute URLs throughout the database: post content, image references, widget settings, theme customiser options, plugin configuration, menu items. All of these need updating from http:// to https://.

The serialisation trap. WordPress stores complex settings as serialised PHP arrays, and serialised strings carry their own character length prefix. Changing http://example.com to https://example.com adds one character. A plain SQL REPLACE updates the string but not the length prefix, and the array becomes unreadable.

The symptom is distinctive: the site works, but widget settings are empty, customiser options have reverted to defaults, and some plugin configuration has silently vanished. Nothing errors. It is simply gone, and if you did not notice for a week, your backup may be gone too.

Use a serialisation-aware tool. WP-CLI's search-replace command handles this correctly. So do the dedicated search-replace scripts and reputable migration plugins. Run a dry run first where the tool supports it, to see how many replacements will occur and where.

Never run raw SQL find-and-replace across wp_options or wp_postmeta.

Update the site URL settings. WordPress Address and Site Address in Settings, both to https://. If these are defined in wp-config.php as constants, change them there instead.

Order matters. Update the database first, then the site URL settings, then verify. Changing the site URL before updating the database can lock you out of the admin area if something is misconfigured.

Check menus and widgets afterwards. Even with a correct replacement, review these visually, since they are where problems surface first.

Step three: fix mixed content

Mixed content is an HTTPS page loading a resource over plain HTTP. Browsers block active mixed content such as scripts and stylesheets outright, and warn about passive mixed content such as images.

The result is a broken padlock, and for blocked scripts, broken functionality.

Find it. Open the browser console on several page types — homepage, a post, a page, a product page, checkout. Mixed content warnings name the offending resource and its URL, which tells you where to look.

Common sources:

Images inserted with absolute HTTP URLs in post content. Usually resolved by the database replacement, but check.

Hardcoded references in theme files. Search the theme directory for http:// and update, preferring protocol-relative or HTTPS URLs.

Plugin settings holding external HTTP URLs, which the database replacement may not catch if the URL is a third-party domain rather than yours.

External resources loaded over HTTP: fonts, scripts, embedded content from third parties. Switch to HTTPS versions. If a third party does not support HTTPS, you need a different provider, because there is no workaround.

Custom CSS with HTTP background image URLs.

Advertising and tracking scripts, some of which are configured with HTTP endpoints.

Add an upgrade-insecure-requests policy as a safety net. This header instructs browsers to upgrade HTTP resource requests to HTTPS automatically. It is a useful backstop, not a substitute for fixing the references, since it does not help where the resource genuinely does not exist over HTTPS.

Recheck after fixing. Mixed content tends to appear on specific page types rather than uniformly, so check a representative sample rather than only the homepage.

Step four: redirects and canonicals

Now consolidate everything onto the HTTPS version.

Add a permanent redirect from HTTP to HTTPS at the server level, in your nginx configuration or .htaccess. Server-level is preferable to a plugin, since it applies before WordPress loads and cannot be disabled accidentally.

Use 301, a permanent redirect. This is what tells search engines the move is permanent and that signals should transfer.

Avoid redirect chains. A request for http://example.com/page should reach https://www.example.com/page in one hop, not via https://example.com/page first. Chains dilute signals and add latency. Combine the protocol and host normalisation into a single rule.

Verify canonical tags. Every page's canonical should now point to the HTTPS version. Most SEO plugins update automatically once the site URL changes, but check the page source on a few pages to confirm.

Regenerate the XML sitemap so it contains HTTPS URLs, and confirm it does.

Update robots.txt if it references your sitemap by absolute URL.

Check hreflang tags if you use them, since they must reference HTTPS versions.

Enable HSTS, but carefully. The Strict-Transport-Security header tells browsers to refuse HTTP connections to your domain entirely. This is a genuine security improvement and it is difficult to reverse, because browsers cache the instruction for the max-age you specify.

Start with a short max-age, perhaps a few hours or a day, confirm everything works across all subdomains, then increase gradually. Do not begin with a long max-age or the preload directive, since undoing that is slow and painful.

Step	Where	Common mistake	Consequence
Install certificate	Host panel	Not covering both www and bare domain	Warning on one version
Verify chain	SSL test tool	Incomplete chain	Fails on some mobile devices
Database URL update	WP-CLI or tool	Raw SQL replace	Serialised settings silently wiped
Site URL settings	Settings or wp-config	Changed before database update	Locked out of admin
Mixed content	Browser console	Only checking homepage	Broken padlock on other templates
301 redirect	Server config	Plugin-based redirect	Can be disabled accidentally
Redirect chains	Server config	Separate protocol and www rules	Diluted signals, added latency
Canonical tags	SEO plugin	Assuming automatic update	Duplicate content signals
Sitemap	SEO plugin	Not regenerated	HTTP URLs submitted to Google
Search Console	Google	Not adding HTTPS property	Lost visibility during migration
HSTS	Server config	Long max-age immediately	Difficult to reverse

Step five: external references

The half that happens outside your site, and the half people forget.

Search Console. Add the HTTPS version as a new property. Google treats HTTP and HTTPS as separate properties, so your existing one stops reporting meaningful data after the migration. Keep both, since the HTTP property shows you the redirect being processed. A Domain property covers both protocols and is the cleaner long-term setup.

Submit the new sitemap in the HTTPS property.

Analytics. Update the default URL in your property settings. Historical data is preserved; this affects reporting and any URL-based configuration.

Ad platforms. Google Ads, Meta, and any other platform with destination URLs. Redirects will handle traffic, but updating the destinations removes a hop and avoids any policy issues with redirecting URLs.

Payment gateway and API callbacks. Webhook and callback URLs registered with your payment gateway, SMS provider, or any integration. These frequently do not follow redirects, and a callback to an HTTP URL can fail silently. This is one of the more damaging omissions.

Social profiles, email signatures, business listings, and directory entries.

Ask key partners to update links. Redirects pass most signal, but direct HTTPS links are cleaner. Focus on your highest-value backlinks rather than attempting everything.

Internal documentation and anything your team uses.

Migration checklist

Condensed, in order:

Back up files and database off-server. Rehearse on staging for complex sites. Note baseline rankings and traffic. Install the certificate and verify it covers both www and bare domain with a complete chain. Confirm HTTPS loads.

Run a serialisation-aware search and replace across the database. Update WordPress Address and Site Address. Verify menus, widgets and customiser settings survived.

Check the browser console on several page types for mixed content and fix each source. Search theme files for hardcoded HTTP references. Add upgrade-insecure-requests as a backstop.

Add a server-level 301 from HTTP to HTTPS, combining protocol and www normalisation into one hop. Verify canonicals point to HTTPS. Regenerate the sitemap. Update robots.txt if it references the sitemap absolutely.

Add the HTTPS property in Search Console and submit the sitemap. Update analytics, ad platform destinations, and every gateway or API callback URL.

Enable HSTS with a short max-age, increase after verification.

Test thoroughly: homepage, posts, pages, archives, search, 404, admin, forms, and checkout if applicable. Test on mobile.

Monitor for two to four weeks.

What to expect afterwards

A brief settling period. Search engines need to recrawl and process the change. Some fluctuation in rankings and impressions over one to four weeks is normal and not a sign of failure.

Search Console data splitting. Your HTTP property's data drops as the HTTPS property picks up. This is expected. Watch the HTTPS property for coverage errors.

Referrer data changes. Traffic from HTTPS sites to HTTP sites loses referrer information; moving to HTTPS actually improves your referrer data. You may see previously "direct" traffic reclassified.

A performance improvement, if you enable HTTP/2 or HTTP/3, which require HTTPS. This frequently offsets the small TLS handshake overhead several times over.

What is not normal: a sustained drop beyond four weeks, pages dropping out of the index, or crawl errors accumulating in Search Console. Those point to a redirect problem, a canonical pointing at the wrong protocol, or a robots.txt issue. Check the redirect chain first, since it is the most common cause.

Monitor Search Console coverage weekly for the first month. Most problems surface there before they show in traffic.

FAQs

Will moving to HTTPS hurt my SEO?

Not if done correctly. Expect a brief settling period of one to four weeks while search engines recrawl and process the change, then rankings should recover and HTTPS is itself a positive ranking signal. Sustained losses indicate a problem, usually redirect chains, canonical tags pointing at the wrong protocol, or a missing Search Console property.

Do I need to add a new Search Console property for HTTPS?

Yes. Google treats HTTP and HTTPS as separate properties, so your existing property stops reporting meaningful data after migration. Add the HTTPS version, submit the new sitemap there, and keep the HTTP property to observe the redirect being processed. A Domain property covers both and is cleaner long term.

How do I update WordPress URLs from HTTP to HTTPS safely?

Use a serialisation-aware tool such as WP-CLI's search-replace command, a dedicated search-replace script, or a reputable migration plugin. Never run a raw SQL find-and-replace across wp_options or wp_postmeta, because serialised PHP arrays carry character length prefixes that a plain replace does not update, silently corrupting widget and theme settings.

Why did my widgets disappear after moving to HTTPS?

Almost certainly a non-serialisation-aware search and replace. Serialised settings store their own string lengths, and a plain replace changes the content without updating the length, making the array unreadable. WordPress then falls back to defaults. Restore from backup and redo the replacement with a proper tool.

What is mixed content and how do I fix it?

Mixed content is an HTTPS page loading resources over plain HTTP. Browsers block scripts and stylesheets loaded this way and warn about images. Find offenders in the browser console across several page types, then fix hardcoded theme references, plugin settings holding external HTTP URLs, custom CSS backgrounds, and third-party scripts. Add upgrade-insecure-requests as a backstop.

Should I use 301 or 302 redirects for HTTPS?

301, a permanent redirect. This signals to search engines that the move is permanent and that ranking signals should transfer to the HTTPS version. A 302 signals a temporary move and does not consolidate signals the same way, which is why using one here is a common and costly error.

What is a redirect chain and why does it matter?

A chain is when a request passes through more than one redirect before reaching its destination, such as HTTP to HTTPS then non-www to www. Chains dilute ranking signals and add latency on every request. Combine protocol and host normalisation into a single rule so any request reaches the final URL in one hop.

Should I enable HSTS immediately?

Enable it, but start with a short max-age of a few hours or a day, confirm everything works across all subdomains, then increase gradually. HSTS instructs browsers to refuse HTTP connections entirely and they cache that instruction for the max-age you set, which makes a mistake with a long value slow and painful to reverse. Avoid preload until you are certain.

What external things need updating after an HTTPS migration?

Search Console property, analytics default URL, ad platform destination URLs, and critically, any payment gateway or API callback and webhook URLs, which frequently do not follow redirects and fail silently. Also social profiles, business listings, email signatures and internal documentation.

Does HTTPS slow down my website?

Marginally at the handshake, and the effect is more than offset if you enable HTTP/2 or HTTP/3, which require HTTPS and bring genuine performance improvements through multiplexing and better connection handling. In practice most sites are faster after migrating, not slower.

Do I need to redirect www and non-www too?

You should normalise to one preferred version regardless, and do it in the same rule as the protocol redirect so requests reach the final URL in one hop. Serving the same content on four variants — HTTP and HTTPS, www and non-www — without consolidation creates duplicate content signals across the whole site.

How long should I monitor after migrating?

Check Search Console coverage weekly for at least a month. Ranking fluctuation within four weeks is normal settling. Beyond that, or if pages drop from the index or crawl errors accumulate, investigate redirects and canonical tags first, since those cause the majority of persistent problems.

Conclusion

HTTPS migration is a site-wide URL change wearing the costume of a checkbox. Handle it as a migration and rankings transfer with a short settling period.

Two steps cause most of the damage, and both are avoidable in a sentence. Use a serialisation-aware tool for the database replacement, never raw SQL, because the failure is silent and destroys settings you may not notice for a week. And add the HTTPS property in Search Console, because Google treats it as a separate property and without it you are blind during the exact period you most need visibility.

After that, the work is mechanical. One redirect rule handling protocol and host together so nothing chains. Canonicals and sitemap on HTTPS. Mixed content cleared from every page type, not just the homepage. HSTS introduced with a short max-age and increased once you are confident.

Then the external half: analytics, ad destinations, and above all the gateway and API callback URLs, which do not follow redirects and fail without telling you.

Monitor Search Console coverage weekly for a month. Fluctuation inside four weeks is normal. Anything persistent past that is almost always a redirect chain or a canonical pointing at the wrong protocol.

HostCloud includes free SSL with automatic renewal, HTTP/3, and server-level redirect configuration on every plan, with free migration if you are moving hosts at the same time. Plans from ₹99 a month at https://hostcloud.in.