Magento stores three separate base URL values — Web/Secure, Web/Unsecure, and the admin base URL — and migrating to HTTPS means all three need to agree, or you end up with a store where browsing works fine but checkout silently breaks or shows mixed content warnings at the worst possible moment.
The three URL settings, explained
Under Stores → Configuration → General → Web → Base URLs, Magento separates the "Unsecure" base URL (used for non-checkout pages historically, though modern stores generally run entirely on HTTPS) from the "Secure" base URL (used for checkout, customer account, and admin pages). For a store fully moving to HTTPS everywhere, set both to the same https:// value, and separately enable "Use Secure URLs in Frontend" and "Use Secure URLs in Admin" so Magento actually applies the secure value across the whole site rather than only specific sections.
Why checkout specifically breaks if this is done incorrectly
Magento's checkout flow and payment gateway integrations frequently generate absolute URLs (for return callbacks after a payment gateway redirect, for example) based on these base URL settings. If the Secure Base URL still points to http:// while your server now forces HTTPS, a payment gateway can redirect a customer back to an http:// URL that then bounces through your redirect — sometimes losing session or cart data in the process, which shows up as customers reporting an empty cart right after attempting payment.
Cache and indexing: the step people skip
Magento aggressively caches generated URLs and configuration. After changing base URL settings, flush the full cache (System → Cache Management → Flush Magento Cache) and reindex if you're on a Magento version with separate indexing. Skipping this step is the single most common reason a correctly configured URL change appears to have no effect — the store keeps serving stale, cached http:// URLs from before the change.
Extensions and themes with hardcoded URLs
Custom themes or third-party extensions occasionally hardcode asset or callback URLs rather than using Magento's URL generation functions correctly — these won't be fixed by changing the base URL settings alone. After migrating, specifically check any custom or heavily modified theme files, and any payment or shipping extension configuration screens, for a separate, extension-specific URL setting that may need updating independently.
Testing checkout specifically, not just browsing
Before considering the migration complete, run a full test transaction (using your payment gateway's sandbox/test mode if available) rather than just clicking through pages — checkout is where base URL misconfigurations actually surface, and a store that looks completely fine while browsing can still have a broken checkout flow underneath.
Multi-store and multi-website setups
Larger Magento installations often run several stores or websites from one installation, each with its own base URL configuration under its own store view scope. A migration needs to check and update base URLs at the correct scope level for each — a change made only at the default/global scope can be silently overridden by a store-view-specific value still pointing at http://, which is a common reason a multi-store Magento migration appears to only partially take effect.
Why Magento's URL rewriting engine adds an extra layer of complexity
Magento generates most of its own internal links dynamically through its URL rewrite system rather than storing fully hardcoded URLs throughout the database the way some simpler platforms do — this is actually helpful during migration, since it means fewer hardcoded http:// references exist to hunt down, but it also means the base URL settings covered earlier need to be exactly correct, since the entire rewrite system depends on them.
What to check in Magento's payment gateway configuration specifically
Beyond the general base URL settings, individual payment method configurations in Magento sometimes store their own separate callback or return URL settings that don't automatically inherit from the store's general base URL change — checking each active payment method's configuration screen after migration, not just the general web settings, catches this specific, easy-to-miss gap.
How to handle a Magento multi-store setup during migration
For a Magento installation running multiple stores or websites, each store view has its own base URL configuration that needs individually correct settings — a change applied only at the default or global scope can be silently overridden by a store-view-specific override still pointing at the old protocol, which is why auditing every store view individually matters for a multi-store migration.
What Magento's Elasticsearch or catalog search index needs after a URL change
Search indexes sometimes cache generated URLs alongside indexed product data — reindexing your catalog search explicitly after completing the base URL migration ensures search results link correctly to https:// product pages rather than any stale, cached http:// references from before the change.
How Magento's CDN integration settings need separate confirmation
If your Magento store uses a CDN for static assets or media, the CDN's own base URL configuration in Magento's admin needs its own explicit update to https://, independent of the general web configuration settings covered earlier — a commonly separate setting that's easy to overlook.
Why staging environment testing matters especially for Magento's complexity
Given how many interconnected settings Magento's HTTPS migration touches, base URLs, cache, indexing, payment gateways, testing the complete sequence against a staging environment first, rather than making changes directly in production, meaningfully reduces the risk of an incomplete or inconsistent live migration.
Why Magento's Full Page Cache needs explicit flushing beyond the general cache
Magento's Full Page Cache (FPC), a separate, more aggressive caching layer than the general application cache, specifically caches rendered HTML output including any embedded URLs — flushing FPC explicitly, not just the general cache, is necessary to ensure visitors actually receive freshly rendered pages reflecting your new https:// base URL rather than a cached pre-migration version.
What Magento's varnish integration means if your store uses it
Stores using Varnish as an additional caching layer in front of Magento need Varnish's own cache cleared as a separate step beyond Magento's internal caching — Varnish operates independently and can continue serving stale, cached responses even after Magento's own cache has been correctly flushed.
How to handle Magento's URL rewrite table if migration seems incomplete
If some pages continue showing incorrect protocol references despite completing the standard steps, directly inspecting Magento's url_rewrite database table can reveal specific stored URL entries that weren't correctly updated — a more advanced troubleshooting step for cases where the standard admin-panel-driven process didn't fully resolve every reference.
Why documenting your specific Magento version matters for future troubleshooting
Magento's exact configuration screens and available options have shifted somewhat across major version releases (1.x, 2.0, 2.4, and Adobe Commerce specifically) — noting your exact version when documenting your migration process, or when seeking help troubleshooting an issue, ensures any guidance you receive or reference actually matches your specific installation's behavior.
A final word on why Magento's migration complexity is worth the effort
Magento's HTTPS migration genuinely involves more distinct configuration surfaces than a simpler platform — base URLs, cache layers, payment gateways, indexing — but each one is individually straightforward once understood, and the resulting store benefits from the same solid, well-tested platform that justified choosing Magento for a complex store in the first place.
What to do once the migration is confirmed stable and complete
Once you've confirmed checkout, admin, and customer-facing pages all work correctly over HTTPS, updating your Search Console property and monitoring for the first few weeks, as covered throughout this site's HTTPS Migration category generally, closes out the migration properly rather than considering the technical steps alone as the finish line.
A quick closing checklist to confirm before considering the migration finished
Before signing off, confirm: base URLs updated at every store-view scope, cache fully flushed including Varnish if used, payment gateway callback URLs verified individually, and a complete test transaction processed successfully — five checks covering the specific failure points this guide has walked through.