WordPress mixed content: fix HTTP resources on an HTTPS page

Recognise mixed content without confusing it with an HTTPS failure

Your page opens over HTTPS, but an image is missing, fonts change, or a form loses its styling. The browser console says “Mixed Content” and mentions a resource requested over HTTP. The main document uses a secure connection; some of what it tries to load still has an insecure address.

The aim is to find where that address is produced, then provide a working HTTPS destination. You do not need to install another plugin to begin. A photo inserted into a post, a generated stylesheet, and a CDN address are not, however, corrected in the same place.

If the browser displays a certificate warning before opening the site, have that certificate checked first. If the page alternates between two addresses and ends with “too many redirects”, examine the HTTPS configuration. Replacing image links does not solve either situation. Likewise, an image already requested over HTTPS that returns a 404 error calls for a file or path diagnosis, not a protocol replacement.

Obtain evidence on the page actually affected

Open the affected public page, then the browser’s developer tools. In Chrome, the Inspect context-menu option opens them. Consult Console and Network, then reload the page with those panels open. Labels may vary with browser language.

Find the mixed-content message and the full address it identifies. In Network, open the corresponding request: record its URL, result, and initiator, meaning what triggered it. The initiator may be the document, a script, or a redirect. This information helps locate the responsible setting.

Do not draw conclusions from every occurrence of http:// in the code. An address quoted in a paragraph is not necessarily loaded. An ordinary link to another page is navigation; an embedded image or script contributes to the current page. Keep one resource as the reference for your first correction.

• Record the page address, resource address, message, and time.
• Specify whether the defect appears logged out, logged in, or both.
• Compare an affected page with a page using the same component without a visible defect.

Understand why some images remain visible

Modern browsers may automatically upgrade some HTTP media requests to HTTPS. Other resources, particularly scripts and stylesheets, are blocked. Behaviour also depends on how media is embedded: not every image receives the same treatment.

An image displayed despite a warning may therefore use an HTTPS address when downloaded while the document retains an HTTP reference. Examine both the console message and the final request. A lasting correction must remove the bad reference at its source rather than relying only on this upgrade.

The appearance of the icon beside the address is not, on its own, a diagnosis. Conversely, no message on the initial load does not cover elements loaded later. Scroll to the gallery and open the relevant menu or tab without submitting a real form just to collect this information.

Verify that the HTTPS destination really exists

For a public image or static file, copy the reported address into a new tab and replace only the initial http:// with https://. Keep the hostname and path. The correct result is the same file, accessible without a certificate warning and without returning to HTTP. Do not replay a payment request or administration action.

If this address shows an invalid certificate, an error page, or another file, stop the replacement. The destination must be repaired or a suitable resource chosen. A certificate covering the main domain does not prove that the media subdomain is configured correctly.

Opening a file directly confirms availability, not necessarily its usability within the page: other rules may still apply. After correction, therefore also check the embedded request. For an external resource without usable HTTPS, ask its provider for the current address or replace the component. Do not allow insecure content in the browser to hide the defect.

Prepare a reversible correction and choose your path

Before editing content, copy the affected block or setting and retain the old address. Before working on the database or files, obtain a dated backup of both, stored privately outside the public directory. Verify that someone knows how to restore it and that hosting access still works if administration becomes inaccessible.

On an active store, an older backup also contains an older order state. It is a fallback and reference; it does not authorise replacing the whole database after an error. Prepare the change on a working copy when its scope exceeds a few fields. From creation, that copy must have its own database; disable real emails, payments, and integrations before its first load, including through WP-CLI.

• Path 1: a few posts, images, or visual settings contain an old address. Use the existing editor and settings.
• Path 2: a migration left many references to the same domain. Prepare a targeted replacement compatible with WordPress data.
• Path 3: HTTP addresses reappear or affect theme, plugin, or CDN resources. Correct the system generating them.

Path 1: correct an image or block in the editor

In Posts or Pages, open the identified content and select the affected image. If it belongs to your media library, use Replace, then the media library, to select the same media whose secure address has been verified. This avoids uploading the file again and creating an unnecessary duplicate. If the media library itself offers an HTTP address, first check the general addresses and configuration described below.

Then check alternative text, caption, any link, and dimensions: correcting the address must not erase those settings. Save, then check the public page and its network request. The field defining the clickable link around an image does not necessarily replace the displayed file’s address.

For a Custom HTML block, first copy its content into your notes, then correct only the identified resource URL. For external media, use the secure address confirmed by its provider. If the same HTTP address returns after saving, do not keep replacing it: move to configuration diagnosis.

If the result is incorrect, restore the saved block or its previous setting. If someone has edited the post in the meantime, recover only the changed element instead of restoring an entire older text revision.

Locate a logo, background, or font

A resource present on several pages sometimes comes from a shared template. With a block theme, find the corresponding block under Appearance, then Editor. With a classic theme, options may be under Appearance, then Customise, or in theme-specific settings. These screens depend on the active theme and your permissions.

Change only the template, logo, or setting identified by your record. A header change may affect the whole site: note its scope before saving and check at least two pages using it. Keep the previous value so it can be restored.

If the initiator is a stylesheet, look for the image or font address in the relevant custom CSS. A background image may be defined in a url(...) rule without appearing as an Image block in the post. Correct that reference after verifying its destination. If the CSS file is generated automatically, change the original setting instead, following the third path.

Check WordPress addresses before bulk processing

On self-hosted WordPress, consult Settings, then General with an authorised account. The WordPress address identifies the installation location; the site address identifies the public address. They may have different paths. Do not make them identical on principle or remove a subdirectory to resolve mixed content.

If the only confirmed discrepancy is HTTP instead of HTTPS, first verify that the secure destinations work and record both values. Then correct the protocol while retaining the intended organisation. Log in again if necessary and check the site. If administration becomes inaccessible, have the host restore only the recorded home and siteurl values, first checking whether configuration constants override them. A full database restoration is not needed to undo these two settings. Tools, then Site Health may also offer native HTTPS migration where applicable; do not force it to appear if your configuration does not support it.

WordPress can rewrite certain older site HTTP URLs when displaying content if configured to do so. This is not a permanent conversion of every piece of data, file, and external domain. Repeat the network check: if the reference resource is already corrected, no bulk replacement is justified.

Path 2: simulate a targeted replacement after migration

This path requires technical access, WP-CLI availability, and certainty that you are in the correct installation. Ask the host to intervene if you lack this access. Some settings contain serialised data: the format records information including string lengths. A raw SQL replacement can make those structures unreadable.

WP-CLI can handle this data. The following example simulates replacing a site-specific address in the posts and post-metadata tables. Replace the example domain and wp_ prefix with verified values. Keep the exact path if resources are in a subdirectory. Never simply replace every http:// with https://.

The --dry-run option does not save replacements to the database; it does not make plugin code loaded at WordPress startup harmless. Start on the isolated copy prepared above. --precise uses the slower PHP processing method. --skip-columns=guid preserves GUID identifiers, which must not be rewritten to clean up links. Examine the tables, columns, and replacement counts reported before applying anything.

wp search-replace 'http://votre-domaine.example/' 'https://votre-domaine.example/' wp_posts wp_postmeta --skip-columns=guid --precise --dry-run

Apply only the scope actually verified

The match count does not prove that every change is desirable. Have examples in the affected fields examined, especially if products, historical content, or builder data share those tables. An unexpected dry run means revisiting the search and scope before continuing.

After validation on the working copy, a recent backup, and rollback preparation, the responsible person may run the validated command again, removing only --dry-run. Keep its report privately. A literal search may miss some encoded addresses: no results does not prove that the page is corrected.

Do not add every table to get more results. Options or plugin tables need separate examination, ideally through their settings. In multisite, have the network administrator identify the exact site and tables; this example does not authorise an operation across all sites.

Without WP-CLI access, the owner with administration access can use the following option after identifying the same scope. Do not use both tools consecutively for the same replacement: choose one path and keep its record.

Without SSH: prepare Better Search Replace and the backup

Better Search Replace is an optional choice for an administrator with many identified references still using HTTP. The listed developer is WP Engine. The current listing states version 1.4.11, minimum WordPress 6.2 and PHP 8.1, and declared compatibility through WordPress 7.1.4. Check your versions in Tools → Site Health → Info before installing.

The free version handles serialised data, selects tables, and simulates replacements. Built-in backup and detailed change comparisons are presented as Pro features: this path does not assume they are available. It requires no purchase.

First obtain a recent independent database backup outside the public directory and verify the recovery method. Make the first attempt on the isolated copy prepared above. Verify its independent database and disabled external effects before opening administration. Without that separation or a recovery solution, limit yourself to manually correcting the few known fields.

In Plugins → Add New Plugin, search for Better Search Replace, verify the developer, install, and activate it. Then open Tools → Better Search Replace. The result of this preparation is an accessible tool on the correct installation with a backup that can genuinely be recovered, not yet a changed database.

Simulate, then apply the same replacement in Better Search Replace

Use the addresses and tables already confirmed during diagnosis. In multisite, selecting a subsite and its tables is the network administrator’s responsibility; do not extend this example to every table. A ticked box or a high match count does not decide the scope for you.

1. In Search for, enter the exact old address, for example http://votre-domaine.example/. In Replace with, enter https://votre-domaine.example/. Replace the example domain, keep necessary subdirectories, and do not search only for http://.
2. In Select tables, select only the confirmed tables, for example posts and their metadata with their actual prefix. Leave Case-Insensitive and Replace GUIDs unticked.
3. Keep Run as dry run selected and click Run Search/Replace. Examine the reported tables and counts; the dry run does not write replacements into the selected fields.
4. If the scope is consistent and reference pages have been validated on the copy, prepare a recent production backup, then use exactly these settings on the correct installation. Untick only Run as dry run to write changes, and run it once.
5. Check the reference resource’s HTTPS request, then the affected pages. If the result is incorrect, have only affected fields recovered from the backup on a copy; use neither a global reverse replacement nor a restoration that overwrites recent orders.

Path 3: repair URLs that are generated again

An old address returning in new pages indicates a source that remains active. Have effective settings compared with the installation configuration. The constants WP_HOME and WP_SITEURL, when present in wp-config.php, override the values WordPress uses without rewriting the values stored in the database. Their presence may also make the corresponding administration fields uneditable.

The person responsible for hosting must therefore identify what actually defines the address before any correction. If they edit a file, they keep a private copy and plan to restore only the changed lines. A complete file should be restored only if no other change has occurred since the copy. Removing a constant at random may reactivate an old database value and lose site access.

If the address is hardcoded in a theme or plugin, send the file and reference to the maintainer. A lasting correction uses appropriate WordPress functions to generate URLs. Avoid an improvised parent-theme edit: it may disappear at the next update. Have the correction validated on the working copy before deployment.

Recreate generated styles after correcting their source

A form may look correct in the editor but lose its styles on the public page. A gallery may work in one post and fail in another. These differences call for comparing resources actually loaded; they do not, on their own, prove that a plugin is faulty.

After correcting the source address, use the existing tool’s documented feature to recreate generated files. For Elementor, current documentation gives Elementor, Editor, Home, then Tools and Clear Files & Data, followed by Save Changes; translations and menus may differ by version. Back up first and limit this intervention to sites actually using that builder.

Do not manually delete the whole uploads directory to achieve the same effect: it also contains original media and may hold other data. After regeneration, record the CSS URL again. If it remains HTTP, return to its source setting. If the address is correct but the old page persists, examine caching.

Handle a CDN or proxy without weakening HTTPS

If resources come from a CDN, check the exact hostname in the service settings or its already installed plugin. Confirm that this name serves the expected files over HTTPS, then correct the protocol or address according to the provider’s configuration. Keep the previous value. Do not arbitrarily replace the CDN domain with the site’s: files may not be available at the same path there.

Behind a reverse proxy, WordPress may receive an HTTP request while the visitor uses HTTPS. Have the host check protocol forwarding and trust in the proxy. Do not copy a snippet that trusts a header supplied by any visitor. Incorrect interpretation may also cause a redirect loop.

An HTTP-to-HTTPS redirect is not enough for a resource blocked before loading. The upgrade-insecure-requests directive can upgrade requests but does not create a missing HTTPS destination. Do not disable certificate verification or reduce TLS security to make a message disappear.

Verify the correction beyond the first page

Start by purging the cached copy of the modified page or file using your existing solution’s controls. A server or CDN cache may persist after the WordPress cache is cleared. Work through identifiable layers and a useful scope; repeated global purges do not correct any source address.

Then revisit the reference page while logged out and in another up-to-date browser. If the defect exists only in one profile, examine its extensions before blaming the site. Use normal browser protections. The expected result combines a correct HTTPS resource, disappearance of its warning, and correct operation of the element.

• Reload the homepage, an affected page, and another page using the same template.
• Trigger the relevant lazy-loaded media, menus, and interactive elements.
• Compare the display at mobile and desktop widths.
• Check administration after changing general addresses.
• If a form is essential, use a designated environment or test mode without creating a real order to check its appearance.

Roll back or provide an actionable diagnosis

If a correction worsens the result, first undo the targeted change: the saved block, previous setting, or relevant file. For database processing, have changed data compared with the backup on a separate copy. A global reverse replacement from HTTPS to HTTP could damage references that were already correct.

Preserve orders, comments, and text saved since the backup. A complete production restoration needs a plan accounting for these additions; it is not the normal rollback for an address correction.

On WordPress.com, certificates are managed by the platform: use the editor for your content and support for configuration unavailable under your plan. In every case, provide the affected page, resource, initiator, exact message, and changes already attempted. Remove cookies, tokens, and private information from records. This case lets the maintainer correct a specific source instead of running several repairs with no demonstrated link to the failure.

Replace an HTTP address written in a PHP template

This case concerns an image supplied with a classic theme whose template contains a fixed HTTP address. It does not replace the correction path for media stored in a post. For a developer, a native function avoids keeping the domain and theme path in the code.

On a working copy, create or adapt the template override in the child theme, then verify that assets/images/illustration.jpg actually exists in the child or parent theme. Replace only the affected image with a fragment suited to its purpose:

An empty alternative attribute is suitable only for a decorative image; for an informative image, supply relevant text. get_theme_file_uri() looks first for the child-theme file, then the parent-theme file. This function generates a URL according to the effective configuration: it does not fix a misconfigured domain, an incorrectly recognised proxy, or a missing file.

After editing, observe the network request on two pages using the template. It must load the correct file over HTTPS without a warning or 404. Retain the useful dimensions and styles of the original image. If the check fails, restore the saved fragment, then correct the URL source before deploying. No database replacement plugin is required for this template file.

<img src="<?php echo esc_url( get_theme_file_uri( 'assets/images/illustration.jpg' ) ); ?>" alt="">