🔍

Troubleshoot mixed content warnings on HostGator

Mixed content appears when an HTTPS page loads part of itself over unencrypted HTTP. The browser may upgrade the request, block it, or mark the page as partly insecure. On HostGator, the usual trigger is an old image, script, stylesheet, iframe, font, API call, or plugin reference left after SSL/TLS was enabled. The warning does not automatically mean a compromised server; it means the page and one dependency disagree about the connection.

Modern browsers handle these resources differently. Scripts, frames, and forms are commonly blocked because an attacker could alter them in transit. Images may be upgraded, displayed with a warning, or removed, leaving a broken layout. Chrome, Edge, Firefox, and Safari use different wording, so one visitor may see a warning that another misses. Australian customers often arrive on a phone, office desktop, or regional connection rather than one controlled test device.

A reliable fix starts by identifying the exact insecure request and correcting its source, not hiding the warning. Back up files and databases before changing WordPress records, plugins, or themes. The HostGator dashboard provides access to cPanel, webmail, invoices, domain tools, tutorials, the knowledge base, support tickets, and forums. Those resources support the workflow, but the live site still needs deliberate testing.

Separate mixed content from other security warnings

Mixed content has a specific meaning: the main document is secure while a subresource uses HTTP. It differs from an expired certificate, hostname mismatch, or a browser security page shown before the site loads. Check the address bar and affected panel first. If https:// itself fails for a subdomain, support may need to confirm the certificate and virtual host; changing content URLs would not repair that.

Active and passive resources carry different risks. An insecure script may be able to execute in the page context, so browsers commonly block it. An insecure image or font mainly damages presentation, yet it can still reveal a referrer or weaken trust at checkout. Treat every HTTP dependency as a defect. Do not use a blanket browser override, weaken HTTPS, or ignore the warning because an embedded resource looks harmless.

Australian domain choices can complicate the diagnosis. Organisations often use .com.au, .net.au, or .org.au while older pages call assets from a .com, CDN, email provider, or booking platform over HTTP. Sydney, Melbourne, and Brisbane stores may combine a local storefront with global suppliers, so the warning can cross several owners. The resource host in the warning identifies where to begin.

Capture the failing request in browser tools

Reproduce the warning while watching browser developer tools. In Chrome or Edge, open Developer Tools, select the Console and Network panels, reload, and look for an insecure request. Firefox’s Console and Network views offer similar evidence. Keep the failing URL exactly as shown; it may contain a misspelled protocol, old folder, query string, or third-party script.

In Safari, use Develop > Show Web Inspector and review the Console, Network, and page elements. Filter network traffic by the host named in the warning, then compare the page and resource URLs. Record the status, whether the request was blocked or upgraded, and the affected page. Repeat in a private window and on a phone to separate a cached copy from a live response and give support a reproducible case.

A third-party page can provide a controlled comparison: the external gaming page is a useful example of a site whose requests can be inspected in Network tools. Use it to recognise the evidence pattern, not as a source of fixes. Test over Australian home NBN, mobile broadband, and a regional link where practical. Different DNS resolvers and caches can delay an old file, so one clean pathway does not clear the site.

Trace the source before editing content

The insecure URL may be generated rather than visible in page source. In WordPress, common origins include post HTML, the Site Address and WordPress Address settings, widgets, custom CSS, themes, plugins, and saved blocks. A theme can hard-code an image URL while a plugin creates a script URL at runtime. Check browser evidence, then search for the exact hostname and path; searching every http:// match creates false positives.

cPanel File Manager exposes public_html and its subdirectories, while database tools permit a controlled WordPress search and replace. Back up first. With SSH, grep can locate file references, and database queries can reveal stored URLs. Record each replacement and limit bulk edits to the exact host and path. Broad changes can break attachments, email links, or supplier feeds on a large membership or e-commerce site.

Classify every match before editing. A HostGator file that supports HTTPS should use HTTPS or a root-relative URL. An external provider may offer a secure endpoint. If it serves only HTTP, replace the component instead of forcing an unsupported protocol. Test direct HTTPS access first, because blind replacement can create a 404 or certificate error. Avoid protocol-relative references because their behaviour depends on the containing page.

Make safe replacements and verify the live site

Work through one origin at a time, starting with the resource in the browser report. Update trusted WordPress core, themes, and plugins, confirm the protocol in Settings > General, and refresh permalinks if the server configuration changes. Replace insecure references with supported HTTPS endpoints. For same-directory assets, a path such as /images/team.jpg can survive a future domain migration. Review CSS url() values, fonts, scripts, iframes, trackers, XML or JSON requests, and background images, not just <img> tags.

A controlled cleanup sequence reduces the risk of introducing unrelated faults:

After each group, test the original journey: home page, navigation, forms, checkout, member area, and support links. Check a mobile viewport and a second browser. A visitor on a fast NBN line can reveal a fault that a cached regional mobile test misses. If shared hosting cannot stage or scan a large site with a heavy media library comfortably, the additional hosting services guide explains larger plans; extra resources improve testing capacity, not the HTTPS setting.

Escalate persistent faults with useful evidence

If the warning survives the documented fixes, open a HostGator ticket with the page URL, exact warning, browser and device, insecure resource URL, Console and Network screenshots, and completed steps. The knowledge base and tutorials cover common SSL, cache, and WordPress cases, while forums help compare symptoms. Ask support to identify the resource host instead of assuming HostGator can change a third-party service.

Published independent hosting reviews can help set expectations for response times and ticket quality. Keep each report focused and add evidence instead of repeating vague messages. If the fault is capacity rather than mixed content, more resources may improve performance, but cannot secure an HTTP endpoint. In the billing and invoices area, confirm whether charges are in AUD, whether GST is itemised, and which card exchange rate applies.

If a compromised plugin injected the reference, rotate credentials, review administrator accounts, remove unauthorised files, and check logs for persistence. Under Australia’s Privacy Act 1988, an organisation must investigate a suspected notifiable data breach and consider notifying the Office of the Australian Information Commissioner when the legal threshold is met. ACSC guidance can support that review. With the evidence gathered, support can get the issue sorted instead of passing it between suppliers.

The next concrete step is one HostGator support ticket containing the failing page URL, warning text, browser details, console screenshot, and insecure resource, with a request to confirm whether the source is account content, WordPress, a plugin, or a third-party host.