{"id":3986,"date":"2026-01-02T16:16:55","date_gmt":"2026-01-02T13:16:55","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/fixing-mixed-content-and-insecure-http-requests-after-enabling-ssl\/"},"modified":"2026-01-02T16:16:55","modified_gmt":"2026-01-02T13:16:55","slug":"fixing-mixed-content-and-insecure-http-requests-after-enabling-ssl","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/fixing-mixed-content-and-insecure-http-requests-after-enabling-ssl\/","title":{"rendered":"Fixing Mixed Content and Insecure HTTP Requests After Enabling SSL"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>After turning on SSL and forcing HTTPS, many websites still show a broken padlock, \u201cNot secure\u201d warnings or partially protected pages. The usual culprit is <strong>mixed content<\/strong>: your HTML loads over HTTPS, but some images, scripts, styles or iframes are still requested over plain HTTP. Browsers block or downgrade these insecure requests, which can break layouts, disable JavaScript and hurt both user trust and SEO. In hosting migrations we handle at dchost.com, mixed content issues are one of the most common sources of confusion after an otherwise successful HTTPS rollout.<\/p>\n<p>In this guide we will walk through practical ways to fix mixed content and insecure HTTP requests in three real-world scenarios: <strong>WordPress sites<\/strong>, <strong>custom PHP applications<\/strong> and setups that sit behind a <strong>CDN or reverse proxy<\/strong>. We will focus on repeatable methods you can apply across projects, not just one-off hacks. By the end, you should have a clear playbook: how to detect mixed content, how to fix it at the source (database, code, templates), how to configure your web server and CDN, and how to safely enable stricter security headers like HSTS and CSP without breaking your site again.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_HTTPS_Breaks_Existing_Sites_Mixed_Content_101\"><span class=\"toc_number toc_depth_1\">1<\/span> Why HTTPS Breaks Existing Sites: Mixed Content 101<\/a><\/li><li><a href=\"#Step_1_Detect_All_Mixed_Content_and_Insecure_HTTP_Requests\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1 \u2013 Detect All Mixed Content and Insecure HTTP Requests<\/a><ul><li><a href=\"#Browser_Developer_Tools\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Browser Developer Tools<\/a><\/li><li><a href=\"#Network_Tab_and_HAR_Exports\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Network Tab and HAR Exports<\/a><\/li><li><a href=\"#Search_in_Code_and_Database\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Search in Code and Database<\/a><\/li><li><a href=\"#Log-_and_Tool-Based_Checks\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Log- and Tool-Based Checks<\/a><\/li><\/ul><\/li><li><a href=\"#Fixing_Mixed_Content_in_WordPress_After_Enabling_SSL\"><span class=\"toc_number toc_depth_1\">3<\/span> Fixing Mixed Content in WordPress After Enabling SSL<\/a><ul><li><a href=\"#1_Fix_the_Core_URLs_in_WordPress_Settings\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. Fix the Core URLs in WordPress Settings<\/a><\/li><li><a href=\"#2_Run_a_Database-Wide_HTTP_HTTPS_Search_Replace\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. Run a Database-Wide HTTP \u2192 HTTPS Search &amp; Replace<\/a><\/li><li><a href=\"#3_Fix_Hard-Coded_URLs_in_Themes_Child_Themes_and_Plugins\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. Fix Hard-Coded URLs in Themes, Child Themes and Plugins<\/a><\/li><li><a href=\"#4_Page_Builders_Widgets_and_Shortcodes\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 4. Page Builders, Widgets and Shortcodes<\/a><\/li><li><a href=\"#5_Mixed_Content_Fixer_Plugins_Helpful_But_Dont_Stop_There\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 5. Mixed Content Fixer Plugins \u2013 Helpful, But Don\u2019t Stop There<\/a><\/li><li><a href=\"#6_Special_Cases_WooCommerce_and_Payments\"><span class=\"toc_number toc_depth_2\">3.6<\/span> 6. Special Cases: WooCommerce and Payments<\/a><\/li><\/ul><\/li><li><a href=\"#Fixing_Mixed_Content_in_Custom_PHP_Applications\"><span class=\"toc_number toc_depth_1\">4<\/span> Fixing Mixed Content in Custom PHP Applications<\/a><ul><li><a href=\"#1_Centralise_and_Correct_Your_Base_URL\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Centralise and Correct Your Base URL<\/a><\/li><li><a href=\"#2_Asset_Helpers_and_Templating_Engines\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Asset Helpers and Templating Engines<\/a><\/li><li><a href=\"#3_Fix_External_API_and_Asset_Calls\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Fix External API and Asset Calls<\/a><\/li><li><a href=\"#4_Enforce_HTTPS_at_the_Web_Server_Level\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. Enforce HTTPS at the Web Server Level<\/a><\/li><li><a href=\"#5_Cookies_Sessions_and_the_Secure_Flag\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. Cookies, Sessions and the Secure Flag<\/a><\/li><\/ul><\/li><li><a href=\"#CDN_Reverse_Proxy_and_Mixed_Content\"><span class=\"toc_number toc_depth_1\">5<\/span> CDN, Reverse Proxy and Mixed Content<\/a><ul><li><a href=\"#1_Decide_the_Source_of_Truth_for_URLs\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Decide the \u201cSource of Truth\u201d for URLs<\/a><\/li><li><a href=\"#2_Use_HTTPS_for_CDN_Asset_URLs\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Use HTTPS for CDN Asset URLs<\/a><\/li><li><a href=\"#3_Respect_Cache-Control_and_Invalidation\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Respect Cache-Control and Invalidation<\/a><\/li><\/ul><\/li><li><a href=\"#Advanced_Tuning_HSTS_CSP_and_Security_Headers_After_Cleanup\"><span class=\"toc_number toc_depth_1\">6<\/span> Advanced Tuning: HSTS, CSP and Security Headers After Cleanup<\/a><ul><li><a href=\"#1_HSTS_HTTP_Strict_Transport_Security\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. HSTS (HTTP Strict Transport Security)<\/a><\/li><li><a href=\"#2_Content_Security_Policy_CSP_and_Mixed_Content\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Content Security Policy (CSP) and Mixed Content<\/a><\/li><li><a href=\"#3_Other_Helpful_Headers\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Other Helpful Headers<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting_and_Infrastructure_Tips_from_the_dchostcom_Team\"><span class=\"toc_number toc_depth_1\">7<\/span> Hosting and Infrastructure Tips from the dchost.com Team<\/a><\/li><li><a href=\"#Wrapping_Up_A_Simple_Playbook_for_Mixed_Content_Cleanup\"><span class=\"toc_number toc_depth_1\">8<\/span> Wrapping Up: A Simple Playbook for Mixed Content Cleanup<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_HTTPS_Breaks_Existing_Sites_Mixed_Content_101\">Why HTTPS Breaks Existing Sites: Mixed Content 101<\/span><\/h2>\n<p>Mixed content happens when a browser loads a page via <strong>HTTPS<\/strong> but finds resources inside that page that still use <strong>HTTP<\/strong>. Example: your page is <code>https:\/\/example.com<\/code>, but an image tag points to <code>http:\/\/example.com\/logo.png<\/code>. From the browser\u2019s perspective, the secure page is now partially dependent on an insecure connection, which opens the door to tampering and eavesdropping.<\/p>\n<p>Modern browsers treat these cases in two ways:<\/p>\n<ul>\n<li><strong>Active mixed content<\/strong> (JavaScript, CSS, iframes, XHR\/fetch requests) is usually <strong>blocked completely<\/strong>. This can break menus, sliders, analytics, payment widgets and more.<\/li>\n<li><strong>Passive mixed content<\/strong> (images, video, audio) may still load, but the browser shows a <strong>\u201cNot fully secure\u201d padlock<\/strong>, which reduces trust and can affect conversion rates.<\/li>\n<\/ul>\n<p>From an SEO and security standpoint, mixed content is more than a cosmetic warning. It can:<\/p>\n<ul>\n<li>Prevent you from getting the full ranking benefits of HTTPS and HTTP\/2\/HTTP\/3.<\/li>\n<li>Block important scripts like A\/B testing, analytics or checkout logic.<\/li>\n<li>Confuse caching and CDN rules, since HTTP and HTTPS URLs may be cached separately.<\/li>\n<\/ul>\n<p>We covered browser-side symptoms in more depth in <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sertifika-hatalari-rehberi-mixed-content-not-secure-ve-tarayici-uyarilarini-hosting-tarafinda-cozmek\/\">our SSL certificate errors guide about mixed content and browser warnings<\/a>. In this article we will focus on <strong>how to actually fix<\/strong> those problems on WordPress, generic PHP apps and CDN-backed setups.<\/p>\n<h2><span id=\"Step_1_Detect_All_Mixed_Content_and_Insecure_HTTP_Requests\">Step 1 \u2013 Detect All Mixed Content and Insecure HTTP Requests<\/span><\/h2>\n<p>Before changing code or running database scripts, you need a reliable inventory of what is still loading over HTTP. Here are the most practical approaches we use when helping customers on our hosting platform.<\/p>\n<h3><span id=\"Browser_Developer_Tools\">Browser Developer Tools<\/span><\/h3>\n<p>Every browser has a built-in console that reports mixed content:<\/p>\n<ul>\n<li>Open your site in <strong>Chrome<\/strong> or <strong>Edge<\/strong>.<\/li>\n<li>Right-click &gt; Inspect &gt; open the <strong>Console<\/strong> tab.<\/li>\n<li>Reload the page over HTTPS.<\/li>\n<\/ul>\n<p>You will see messages like <code>Mixed Content: The page at 'https:\/\/example.com' was loaded over HTTPS, but requested an insecure image 'http:\/\/example.com\/logo.png'<\/code>. Note the full URLs and file types \u2013 this will guide where you need to fix things (content, theme, plugin, CDN, etc.).<\/p>\n<h3><span id=\"Network_Tab_and_HAR_Exports\">Network Tab and HAR Exports<\/span><\/h3>\n<p>The <strong>Network<\/strong> tab in dev tools lets you filter hard-to-see requests:<\/p>\n<ul>\n<li>Open Network, check \u201cPreserve log\u201d, then reload.<\/li>\n<li>Filter by \u201cscheme\u201d or search for <code>http:\/\/<\/code> in the URL column.<\/li>\n<li>Export as HAR if you want a sharable report.<\/li>\n<\/ul>\n<p>This is useful for spotting <strong>AJAX requests<\/strong>, <strong>font files<\/strong> or <strong>third-party widgets<\/strong> that still use HTTP.<\/p>\n<h3><span id=\"Search_in_Code_and_Database\">Search in Code and Database<\/span><\/h3>\n<p>On WordPress and custom PHP projects, the root cause is almost always <strong>hard-coded HTTP URLs<\/strong> in the database or source files.<\/p>\n<ul>\n<li><strong>File search:<\/strong> Use <code>grep<\/code>, your IDE or a code search tool to look for <code>http:\/\/yourdomain.com<\/code> inside your theme, plugins and custom PHP files.<\/li>\n<li><strong>Database search:<\/strong> For WordPress, a <code>wp search-replace<\/code> via WP-CLI or a serialized-aware search\/replace tool helps find old HTTP URLs in <code>wp_posts<\/code>, <code>wp_options<\/code> and widget tables.<\/li>\n<\/ul>\n<p>Always run database changes in <strong>dry-run mode<\/strong> first or take a full backup (database + files). Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/\">WordPress backup strategies on shared hosting and VPS<\/a> is a good companion before doing any bulk operations.<\/p>\n<h3><span id=\"Log-_and_Tool-Based_Checks\">Log- and Tool-Based Checks<\/span><\/h3>\n<p>On <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, access logs can also reveal mixed content:<\/p>\n<ul>\n<li>Filter your web server logs for <code>\"GET http:\/\/\"<\/code> or known asset paths.<\/li>\n<li>Use CLI tools like <code>curl<\/code> to fetch pages and grep for <code>http:\/\/<\/code>.<\/li>\n<\/ul>\n<p>Once you have a list of insecure URLs, grouping them by pattern (same directory, same plugin, same widget) makes the cleanup much faster.<\/p>\n<h2><span id=\"Fixing_Mixed_Content_in_WordPress_After_Enabling_SSL\">Fixing Mixed Content in WordPress After Enabling SSL<\/span><\/h2>\n<p>WordPress is both the easiest and the trickiest platform for mixed content: easy because there are standard settings, tricky because plugins, page builders and serialized data can hide HTTP URLs in many places. Below is the sequence we recommend when customers move their WordPress sites to HTTPS on our shared hosting, VPS or dedicated servers.<\/p>\n<h3><span id=\"1_Fix_the_Core_URLs_in_WordPress_Settings\">1. Fix the Core URLs in WordPress Settings<\/span><\/h3>\n<p>Start with WordPress\u2019s own idea of your URL:<\/p>\n<ol>\n<li>Log in to <strong>wp-admin<\/strong>.<\/li>\n<li>Go to <strong>Settings &gt; General<\/strong>.<\/li>\n<li>Update <strong>WordPress Address (URL)<\/strong> and <strong>Site Address (URL)<\/strong> from <code>http:\/\/example.com<\/code> to <code>https:\/\/example.com<\/code>.<\/li>\n<\/ol>\n<p>On some managed environments or when using <code>wp-config.php<\/code> constants like <code>WP_HOME<\/code> and <code>WP_SITEURL<\/code>, you may need to update those instead. After this change, new internal links should automatically be generated with HTTPS.<\/p>\n<h3><span id=\"2_Run_a_Database-Wide_HTTP_HTTPS_Search_Replace\">2. Run a Database-Wide HTTP \u2192 HTTPS Search &amp; Replace<\/span><\/h3>\n<p>Existing content (posts, pages, widgets, shortcodes) usually still contains old HTTP URLs. The cleanest long-term solution is a <strong>one-time search and replace<\/strong> in the database:<\/p>\n<ul>\n<li>Use a serialized-aware tool (WP-CLI <code>wp search-replace<\/code> or a trusted migration plugin) to replace <code>http:\/\/example.com<\/code> with <code>https:\/\/example.com<\/code>.<\/li>\n<li>Include all core tables (<code>wp_posts<\/code>, <code>wp_postmeta<\/code>, <code>wp_options<\/code>, <code>wp_terms<\/code>, etc.) and custom tables created by major plugins.<\/li>\n<li>Run a dry run first to see how many changes will be made, then run the real operation.<\/li>\n<\/ul>\n<p>This takes care of most images, internal links and embedded media pointing back to your own domain. For more context around redirects and SEO-safe changes, you can compare this step with the move scenarios in <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">our full HTTPS migration guide with 301 redirects and HSTS<\/a>.<\/p>\n<h3><span id=\"3_Fix_Hard-Coded_URLs_in_Themes_Child_Themes_and_Plugins\">3. Fix Hard-Coded URLs in Themes, Child Themes and Plugins<\/span><\/h3>\n<p>Many older themes and customizations contain hard-coded URLs in PHP templates, CSS or JavaScript files. Typical places:<\/p>\n<ul>\n<li><code>header.php<\/code> or <code>footer.php<\/code> linking to <code>http:\/\/example.com\/style.css<\/code> or external fonts.<\/li>\n<li>Custom logo or background URLs in the theme\u2019s options framework stored as HTTP.<\/li>\n<li>Inline JavaScript that references <code>http:\/\/<\/code> analytics or tracking endpoints.<\/li>\n<\/ul>\n<p>Best practice is to <strong>avoid hard-coding the protocol<\/strong>. In WordPress PHP templates, use helpers like:<\/p>\n<ul>\n<li><code>home_url()<\/code>, <code>site_url()<\/code> and <code>plugins_url()<\/code> which are aware of HTTPS.<\/li>\n<li><code>wp_enqueue_style()<\/code> and <code>wp_enqueue_script()<\/code> with protocol-agnostic URLs or HTTPS endpoints.<\/li>\n<\/ul>\n<p>If you maintain custom themes for clients, adding \u201cno hard-coded <code>http:\/\/<\/code>\u201d to your coding standards will save a lot of future debugging.<\/p>\n<h3><span id=\"4_Page_Builders_Widgets_and_Shortcodes\">4. Page Builders, Widgets and Shortcodes<\/span><\/h3>\n<p>Visual page builders and widget frameworks often store full URLs in their own data structures. After a global search\/replace, you may still see mixed content for:<\/p>\n<ul>\n<li>Background images configured in a page builder\u2019s design panel.<\/li>\n<li>Button links, icon lists, or \u201cimage box\u201d widgets pointing to HTTP.<\/li>\n<li>Custom HTML widgets with manually typed <code>http:\/\/<\/code> links.<\/li>\n<\/ul>\n<p>Approach:<\/p>\n<ul>\n<li>Identify which pages still show mixed content in the browser console.<\/li>\n<li>Edit those specific pages in the builder and re-save, ensuring all URLs are HTTPS.<\/li>\n<li>Search your widgets for any <code>http:\/\/<\/code> references and update them.<\/li>\n<\/ul>\n<p>For big sites, this can be a gradual process: fix the most visited pages first (home, product\/category pages, landing pages), then work through the rest.<\/p>\n<h3><span id=\"5_Mixed_Content_Fixer_Plugins_Helpful_But_Dont_Stop_There\">5. Mixed Content Fixer Plugins \u2013 Helpful, But Don\u2019t Stop There<\/span><\/h3>\n<p>There are plugins that scan and rewrite HTTP URLs on the fly to HTTPS using output buffering. We see agencies use them as a quick fix during migrations, and that\u2019s fine as a <strong>temporary safety net<\/strong>. However, relying on them permanently has drawbacks:<\/p>\n<ul>\n<li>Extra processing on every request, which can hurt performance.<\/li>\n<li>Harder to debug issues when you don\u2019t know whether a URL came from the database or was rewritten dynamically.<\/li>\n<li>Doesn\u2019t fix the underlying data; any external integration that bypasses WordPress (RSS, API, SEO tools) may still see HTTP URLs.<\/li>\n<\/ul>\n<p>Our recommendation: use such plugins to <strong>catch anything you missed<\/strong> during migration, but still clean your database and code so that the plugin eventually becomes unnecessary.<\/p>\n<h3><span id=\"6_Special_Cases_WooCommerce_and_Payments\">6. Special Cases: WooCommerce and Payments<\/span><\/h3>\n<p>E-commerce brings additional mixed content sources:<\/p>\n<ul>\n<li>Product images or downloadable files referenced with HTTP in old product descriptions.<\/li>\n<li>Gateway or iframe-based payment methods that load external assets over HTTP.<\/li>\n<li>Custom checkout scripts or validation endpoints pointing to <code>http:\/\/<\/code>.<\/li>\n<\/ul>\n<p>Steps:<\/p>\n<ul>\n<li>Run search\/replace on product descriptions and custom fields.<\/li>\n<li>Check each payment gateway\u2019s documentation for HTTPS requirements and update any callback URLs.<\/li>\n<li>Test cart and checkout thoroughly with browser dev tools open to watch for blocked scripts.<\/li>\n<\/ul>\n<p>For a broader look at how HTTPS interacts with PCI-DSS and hosting choices, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/pci-dss-uyumlu-e-ticaret-hosting-rehberi\/\">PCI\u2011DSS-compliant e\u2011commerce hosting, including SSL, logs and backups<\/a>.<\/p>\n<h2><span id=\"Fixing_Mixed_Content_in_Custom_PHP_Applications\">Fixing Mixed Content in Custom PHP Applications<\/span><\/h2>\n<p>For Laravel, Symfony and other custom PHP apps (including in-house frameworks), the principles are similar but you have more direct control. At dchost.com, we often see three root causes: base URL configuration, hard-coded asset paths and cookies\/sessions not being marked as secure.<\/p>\n<h3><span id=\"1_Centralise_and_Correct_Your_Base_URL\">1. Centralise and Correct Your Base URL<\/span><\/h3>\n<p>Most frameworks have a <strong>single base URL<\/strong> or \u201capp URL\u201d setting:<\/p>\n<ul>\n<li>Laravel: <code>APP_URL=https:\/\/example.com<\/code> in <code>.env<\/code>.<\/li>\n<li>Symfony: router configuration, framework settings, or trusted proxies settings.<\/li>\n<li>Custom apps: a config file like <code>config.php<\/code> that defines <code>BASE_URL<\/code>.<\/li>\n<\/ul>\n<p>Make sure this value uses <strong>https:\/\/<\/strong>, and use that configuration variable everywhere instead of concatenating <code>\"http:\/\/\"<\/code> strings in templates or controllers. Updating this one place can automatically fix many generated URLs.<\/p>\n<h3><span id=\"2_Asset_Helpers_and_Templating_Engines\">2. Asset Helpers and Templating Engines<\/span><\/h3>\n<p>Use your framework\u2019s asset helpers instead of manual URLs:<\/p>\n<ul>\n<li>Laravel\u2019s <code>asset()<\/code>, <code>url()<\/code>, <code>route()<\/code> helpers respect HTTPS if your app is correctly configured.<\/li>\n<li>In Twig\/Blade or custom view layers, ensure links are generated with routes, not hard-coded <code>http:\/\/<\/code> prefixes.<\/li>\n<\/ul>\n<p>If your app sits behind a reverse proxy or load balancer that terminates SSL, configure <strong>trusted proxies<\/strong> so the framework knows the original scheme is HTTPS (e.g. <code>X-Forwarded-Proto: https<\/code>). Otherwise it may keep generating HTTP URLs even though the user sees HTTPS at the edge.<\/p>\n<h3><span id=\"3_Fix_External_API_and_Asset_Calls\">3. Fix External API and Asset Calls<\/span><\/h3>\n<p>Many mixed content problems in custom apps come from:<\/p>\n<ul>\n<li>Loading external JS\/CSS libraries from <code>http:\/\/cdn.example.com<\/code>.<\/li>\n<li>Embedding third-party widgets in iframes with HTTP URLs.<\/li>\n<li>AJAX calls to unsecured APIs on your own subdomains.<\/li>\n<\/ul>\n<p>Wherever possible, switch to <strong>HTTPS endpoints<\/strong> provided by those third parties. If no HTTPS endpoint exists and the resource is critical, you may need to:<\/p>\n<ul>\n<li>Host the asset yourself over HTTPS (with license compliance in mind).<\/li>\n<li>Proxy the request through your own backend that exposes an HTTPS URL.<\/li>\n<\/ul>\n<p>Remember that browsers increasingly <strong>block<\/strong> active mixed content; the workaround of \u201cjust ignore it\u201d no longer works.<\/p>\n<h3><span id=\"4_Enforce_HTTPS_at_the_Web_Server_Level\">4. Enforce HTTPS at the Web Server Level<\/span><\/h3>\n<p>Your app should behave as if HTTPS is the default. Ensure you also enforce it at the web server level:<\/p>\n<ul>\n<li><strong>Apache (.htaccess):<\/strong> create or update rules to redirect all HTTP traffic to HTTPS with a 301 status.<\/li>\n<li><strong>Nginx:<\/strong> have a separate server block listening on port 80 that returns a 301 redirect to the HTTPS version.<\/li>\n<\/ul>\n<p>We go into detail about 301 redirects, canonical URLs and SEO-safe changes in <a href=\"https:\/\/www.dchost.com\/blog\/en\/seo-kaybi-olmadan-url-yapisini-degistirmek-htaccess-ve-nginx-301-yonlendirme-rehberi\/\">our guide to SEO\u2011safe URL structure changes with 301 redirects<\/a>, which pairs nicely with an HTTPS migration.<\/p>\n<h3><span id=\"5_Cookies_Sessions_and_the_Secure_Flag\">5. Cookies, Sessions and the Secure Flag<\/span><\/h3>\n<p>Mixed content is often discussed purely in terms of assets, but <strong>cookie security<\/strong> matters too. Once your site runs on HTTPS:<\/p>\n<ul>\n<li>Set <code>Secure<\/code> and <code>HttpOnly<\/code> flags on session cookies so they cannot be sent over HTTP.<\/li>\n<li>Use <code>SameSite=Lax<\/code> or <code>Strict<\/code> where possible, especially for admin or account areas.<\/li>\n<\/ul>\n<p>We explored cookie flags and how to configure them in web servers and apps in <a href=\"https:\/\/www.dchost.com\/blog\/en\/samesitelax-mi-strict-mi-secure-ve-httponly-ile-nginx-apachede-cerezleri-tertemiz-nasil-kurarsin\/\">our guide to SameSite, Secure and HttpOnly cookies<\/a>. While cookies are not \u201cmixed content\u201d in the classic sense, getting them right is part of the same overall HTTPS hardening process.<\/p>\n<h2><span id=\"CDN_Reverse_Proxy_and_Mixed_Content\">CDN, Reverse Proxy and Mixed Content<\/span><\/h2>\n<p>CDNs and reverse proxies introduce another layer of complexity. A common pattern we see for new dchost.com customers is this:<\/p>\n<ul>\n<li>Your origin server is still accessible via HTTP (e.g. <code>http:\/\/origin.example.com<\/code>).<\/li>\n<li>The CDN provides an HTTPS-enabled URL (e.g. <code>https:\/\/www.example.com<\/code>).<\/li>\n<li>Some assets in your HTML still point directly to the origin with <code>http:\/\/origin.example.com\/file.js<\/code>.<\/li>\n<\/ul>\n<p>The browser does not care that a CDN is involved \u2013 it still sees HTTP vs HTTPS and flags mixed content. To fix this cleanly:<\/p>\n<h3><span id=\"1_Decide_the_Source_of_Truth_for_URLs\">1. Decide the \u201cSource of Truth\u201d for URLs<\/span><\/h3>\n<p>Pick <strong>one canonical domain<\/strong> and scheme for public access, usually <code>https:\/\/www.example.com<\/code> or <code>https:\/\/example.com<\/code> behind the CDN. Then ensure:<\/p>\n<ul>\n<li>Your application generates URLs pointing to that canonical domain.<\/li>\n<li>The CDN is configured to fetch from your origin via HTTP or HTTPS as appropriate, but this is invisible to the browser.<\/li>\n<\/ul>\n<p>Don\u2019t mix public URLs that go directly to the origin and others that go via the CDN unless you have a very specific reason (and even then, keep them all HTTPS).<\/p>\n<h3><span id=\"2_Use_HTTPS_for_CDN_Asset_URLs\">2. Use HTTPS for CDN Asset URLs<\/span><\/h3>\n<p>If you use a separate CDN hostname for static files (e.g. <code>static.examplecdn.com<\/code>):<\/p>\n<ul>\n<li>Enable an <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a> for that CDN hostname.<\/li>\n<li>Update asset URLs in your app or WordPress plugin settings to use <code>https:\/\/static.examplecdn.com<\/code> rather than <code>http:\/\/<\/code>.<\/li>\n<li>Avoid protocol-relative URLs (<code>\/\/static.examplecdn.com<\/code>) if they cause confusion with proxies or security scanners; explicit <code>https:\/\/<\/code> is usually clearer.<\/li>\n<\/ul>\n<p>If you are still deciding whether to introduce a CDN, we explain the trade-offs in <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-nedir-ne-zaman-gerekir-trafik-ve-lokasyona-gore-karar-rehberi\/\">our practical CDN decision guide<\/a>, including traffic patterns and geography.<\/p>\n<h3><span id=\"3_Respect_Cache-Control_and_Invalidation\">3. Respect Cache-Control and Invalidation<\/span><\/h3>\n<p>Once everything is on HTTPS, you want the CDN to cache aggressively to benefit from reduced latency and offloaded traffic. But when cleaning mixed content, you\u2019ll be frequently changing assets. Make sure you:<\/p>\n<ul>\n<li>Use <strong>versioned file names<\/strong> or cache-busting query strings (e.g. <code>style.css?v=2<\/code>).<\/li>\n<li>Configure <code>Cache-Control<\/code> and <code>ETag<\/code> headers correctly so that browsers and CDNs revalidate when necessary.<\/li>\n<li>Know how to purge specific URLs or tags from your CDN cache when you correct mixed content sources.<\/li>\n<\/ul>\n<p>We explored these headers and their interaction with CDNs in detail in <a href=\"https:\/\/www.dchost.com\/blog\/en\/tarayici-ve-cdn-onbellekleme-neden-bu-kadar-kritik\/\">our HTTP cache-control and CDN rules guide for faster sites<\/a>. After an HTTPS migration, revisiting those rules is a good idea.<\/p>\n<h2><span id=\"Advanced_Tuning_HSTS_CSP_and_Security_Headers_After_Cleanup\">Advanced Tuning: HSTS, CSP and Security Headers After Cleanup<\/span><\/h2>\n<p>Once you have removed mixed content and the site is consistently served over HTTPS, you can safely enable stricter <strong>HTTP security headers<\/strong> to harden your setup.<\/p>\n<h3><span id=\"1_HSTS_HTTP_Strict_Transport_Security\">1. HSTS (HTTP Strict Transport Security)<\/span><\/h3>\n<p>HSTS tells browsers to always use HTTPS for your domain, even if a user or script tries to access it via HTTP. Example header:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<\/code><\/pre>\n<p>Introduce HSTS gradually:<\/p>\n<ul>\n<li>Start with a small <code>max-age<\/code> (e.g. a few minutes or hours) and test thoroughly.<\/li>\n<li>Increase to longer periods (e.g. 6\u201312 months) once you are confident.<\/li>\n<li>Only add <code>preload<\/code> and submit to the browser preload list when you are sure there are no HTTP-only endpoints left.<\/li>\n<\/ul>\n<p>We provide a step-by-step breakdown of HSTS and related headers in <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/\">our HTTP security headers guide for HSTS, CSP and more<\/a>.<\/p>\n<h3><span id=\"2_Content_Security_Policy_CSP_and_Mixed_Content\">2. Content Security Policy (CSP) and Mixed Content<\/span><\/h3>\n<p>CSP lets you explicitly declare which sources are allowed for scripts, styles, images and more. It can also help prevent future mixed content regressions:<\/p>\n<ul>\n<li>Use <code>upgrade-insecure-requests<\/code> to tell compatible browsers to treat <code>http:\/\/<\/code> URLs as <code>https:\/\/<\/code> where possible.<\/li>\n<li>Use <code>block-all-mixed-content<\/code> to forbid any HTTP resources entirely once you are sure everything is clean.<\/li>\n<\/ul>\n<p>Start with <code>Content-Security-Policy-Report-Only<\/code> so you can see what would be blocked before enforcing it in production. This gives you time to adjust external scripts and images without impacting users.<\/p>\n<h3><span id=\"3_Other_Helpful_Headers\">3. Other Helpful Headers<\/span><\/h3>\n<p>While not directly related to mixed content, it is a good time to set:<\/p>\n<ul>\n<li><code>X-Frame-Options<\/code> or <code>frame-ancestors<\/code> to control framing.<\/li>\n<li><code>Referrer-Policy<\/code> to limit referrer data leakage.<\/li>\n<li><code>X-Content-Type-Options: nosniff<\/code> to prevent MIME type sniffing.<\/li>\n<\/ul>\n<p>These all work best when your site is consistently served over HTTPS. Combining them with a clean mixed-content-free setup significantly raises the barrier for common web attacks.<\/p>\n<h2><span id=\"Hosting_and_Infrastructure_Tips_from_the_dchostcom_Team\">Hosting and Infrastructure Tips from the dchost.com Team<\/span><\/h2>\n<p>Many mixed content headaches come from partial or inconsistent HTTPS setups on the hosting side. When you run your site on dchost.com shared hosting, VPS or dedicated servers, we recommend:<\/p>\n<ul>\n<li><strong>Always enabling SSL<\/strong> on your primary domain and key subdomains, ideally using free and automated certificates so they renew without manual effort.<\/li>\n<li>Setting <strong>automatic HTTP \u2192 HTTPS redirects<\/strong> at the web server or control panel level to make HTTPS the only public entry point.<\/li>\n<li>Using HTTP\/2 or HTTP\/3 support on your hosting plan to get the performance benefits that make HTTPS migrations feel like an upgrade, not just a security chore.<\/li>\n<li>Keeping a consistent environment between staging and production so you can catch mixed content in a staging URL before cutting over DNS.<\/li>\n<\/ul>\n<p>If you do not yet have SSL enabled, start with <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-ile-ucretsiz-ssl-sertifikasi-kurulumu-cpanel-ve-directadminde-otomatik-yenileme-rehberi\/\">our guide on why free SSL with Let&#039;s Encrypt matters and how to enable it on cPanel and DirectAdmin<\/a>. That article covers certificate issuance and automation; this one helps you clean up the application side afterward.<\/p>\n<h2><span id=\"Wrapping_Up_A_Simple_Playbook_for_Mixed_Content_Cleanup\">Wrapping Up: A Simple Playbook for Mixed Content Cleanup<\/span><\/h2>\n<p>Fixing mixed content and insecure HTTP requests after enabling SSL is less about magic and more about following a clear sequence. First, <strong>detect<\/strong> all HTTP resources via browser dev tools, code\/database searches and logs. Second, <strong>fix URLs at the source<\/strong>: update WordPress settings and database entries, clean hard-coded URLs in themes and plugins, and centralize base URLs and asset helpers in custom PHP apps. Third, <strong>align your hosting and CDN<\/strong> so that everything consistently uses HTTPS from the user\u2019s perspective, with proper redirects, cache rules and CDN hostnames.<\/p>\n<p>Only after the site is clean should you tighten the screws with <strong>HSTS, CSP and other security headers<\/strong> to prevent regressions and raise your overall security level. As a hosting team, we see that sites which treat HTTPS as a first-class requirement from day one have far fewer surprises later on. If you are planning a migration to HTTPS or moving your WordPress or PHP application to a new environment, our team at dchost.com can help you choose the right shared hosting, VPS or dedicated server and configure SSL, redirects and security headers correctly from the start.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>After turning on SSL and forcing HTTPS, many websites still show a broken padlock, \u201cNot secure\u201d warnings or partially protected pages. The usual culprit is mixed content: your HTML loads over HTTPS, but some images, scripts, styles or iframes are still requested over plain HTTP. Browsers block or downgrade these insecure requests, which can break [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3987,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3986","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3986","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3986"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3986\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3987"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3986"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3986"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3986"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}