How to use Webyzer to check for mixed content warnings
Mixed content occurs when an HTTPS page loads a resource over plain HTTP. Depending on the resource, a browser may block it, replace it with an insecure version, or display a warning in the address bar and developer console. The issue is more than cosmetic: it can expose page behaviour to interception and break scripts, fonts, images, video, or checkout functions. Identifying the responsible assets is safer than changing every HTTP URL at random.
Webyzer provides a practical way to review a domain’s technology, loading behaviour, and security-related findings from one report. Use it to spot mixed-content indicators, then confirm each affected request in your browser and locate its source in the site files or third-party configuration. The workflow applies to .com.au and .au sites, WordPress builds, Shopify stores, custom applications, and websites managed by Australian agencies.
Understand what mixed content means
A normal HTTP link does not create mixed content unless the browser loads it automatically as part of an HTTPS page. An image requested by the page, for example, can trigger the warning even when no visitor clicks an insecure link. This distinction helps narrow the search to embedded resources, stylesheets, scripts, frames, fonts, and media files.
There are two broad categories of mixed content. Active content includes scripts, stylesheets, frames, and certain fonts; browsers commonly block these because they could modify or intercept the secure page. Passive content generally consists of images, audio, and video. Some browsers automatically upgrade passive requests to HTTPS, while others display a less severe warning. Either category deserves attention because automatic upgrades can still produce broken visuals or inconsistent behaviour.
Mixed content is also different from an invalid SSL certificate. A certificate problem affects the secure connection to the website itself, whereas a mixed-content warning means the secure page is loading an insecure subresource. A domain can have a valid certificate and still suffer from insecure asset URLs embedded in its templates, content, scripts, or external services.
Why Australian sites need a careful check
Many Australian websites use both an apex domain and a www version, such as example.com.au and www.example.com.au. A redirect between them can expose legacy HTTP references if the destination page was not properly secured. When checking a domain, record the exact hostname used by the scan and follow any redirects before assessing the final page.
For businesses serving customers in Sydney, Melbourne, Brisbane, Perth, and regional centres, a blocked script can affect more than appearance. An Australian store displaying prices in AUD with GST included may rely on JavaScript to calculate delivery, apply discounts, or pass details to a payment provider. A failing map, booking widget, or analytics script can also interrupt a sale or enquiry while the rest of the site appears normal.
Secure transport supports customer confidence and the safeguards expected under the Australian Privacy Act and Australian Privacy Principles, although HTTPS alone does not establish privacy compliance. Seasonal campaigns such as the Melbourne Cup, end-of-financial-year promotions, and Christmas sales often introduce temporary landing pages, advertising scripts, and embedded media. These releases are useful checkpoints for a mixed-content audit.
Run a Webyzer domain analysis
Open the Webyzer analysis page and enter the website address in the domain check field. Start with the canonical HTTPS homepage, then check the alternate www or apex version if the first scan does not show the expected redirect. Remove tracking parameters, unnecessary paths, and spaces from the submitted address so that the tool evaluates the intended domain rather than a single campaign URL.
Allow the scan to finish before drawing conclusions. Webyzer can gather information about loading statistics, technology, domain metrics, and browser or security-related findings, including mixed-content indicators. Note the date and the exact URL that produced each result. A scan is a snapshot, and an issue may disappear when cached files are purged or a third-party service changes its response.
If Webyzer reports that the submitted domain is invalid or restricted, confirm that the domain resolves publicly and that the hostname is entered correctly. Try the root domain instead of a deep link, or switch between www and the non-www address. Pages behind authentication, firewalls, local networks, or unpublished staging environments may not be accessible to a remote scanner and need a separate browser-based review.
Read the security and loading results
Open any mixed-content or warning entry in the Webyzer report and record the affected resource URL, its type, and the page on which it appeared. An image URL has a different cause from a blocked payment script, while a stylesheet may point to an old font or background asset. The resource type helps determine whether the problem affects security, appearance, functionality, or all three.
Check whether the request is owned by the website or supplied by a third party. First-party assets often come from a CMS template, hard-coded HTML, CSS, JavaScript, or stored content. Third-party requests may originate from an advertising tag, chat widget, embedded video, map, CDN, or payment provider. A URL written into a script but never loaded might appear in a general audit without producing a browser warning, so avoid treating every plain-HTTP reference as identical.
Keep the diagnosis separate from on-page SEO metrics, because a secure page loading an insecure resource affects browser trust and functionality even when rankings are unchanged. Technical mixed-content findings belong with security and implementation checks. They can also influence engagement metrics if images, calls to action, or checkout elements stop working.
Trace and fix insecure resources
Correct the source of the request rather than suppressing the browser warning. In the CMS, search templates and content for http:// references, then inspect CSS files for background images and fonts. JavaScript bundles may contain API endpoints, image sources, or dynamically loaded resources that are not obvious in the visible page source. Replace required HTTP addresses with their HTTPS equivalents and remove resources that are no longer needed.
External services require a different approach. Check the vendor’s documentation for an HTTPS endpoint, update the embed code, and test any related cookies, callbacks, or permissions. If a provider offers no secure version, remove the resource or choose an alternative. Self-hosting an approved asset can sometimes resolve the problem, but it also transfers performance, security, and update responsibilities to the site owner. Do not add a Content Security Policy merely to hide the warning; policies should reflect the resources the site actually requires.
After updating the files, clear the WordPress, Shopify, application, and CDN caches as appropriate. Check server redirect rules, reverse-proxy settings, and deployment artefacts for references that still contain http://. A stale cached page may keep requesting an insecure resource even though the current template is correct. Never disable browser security controls or tell visitors to ignore the warning, as that would conceal a genuine transport weakness.
Verify the repair in every browser
Open the affected page in Chrome, Edge, Firefox, and Safari, especially if your audience uses different devices and operating systems. In the browser’s developer tools, inspect the Console and Network panels, reload without cached files, and search for mixed-content or insecure requests. The Network panel can reveal the exact resource and its initiator, while the Console often provides a direct warning tied to the blocked URL.
Repeat the verification on important landing pages rather than testing only the homepage. For an online store, check a product page, cart, checkout, and confirmation screen. For a service business, check contact forms, booking calendars, maps, and video embeds. Some third-party assets appear only for particular locations, campaign settings, consent choices, or browser conditions, so testing a clean session and a returning session can reveal differences.
To familiarise yourself with a public scan, you can use the same viewing process on 19 Tamal Vista, while making changes only on domains you control. Run Webyzer again after the repair and compare the result with the original findings. If the warning remains, retain the page URL, screenshot, timestamp, and browser details; that evidence makes the problem easier for a developer or hosting provider to reproduce.
Make mixed-content checks a routine
Create a baseline covering the homepage and every high-value page type. For an Australian retailer, that may include product, cart, checkout, delivery, and policy pages; for a tourism operator, it may include itinerary, enquiry, booking, and gallery pages. Record whether the domain redirects from HTTP to HTTPS, whether both hostname variants resolve correctly, and whether known assets load securely.
Schedule another scan after migrations, redesigns, plugin updates, CDN changes, and significant third-party campaigns. Assign responsibility for reviewing warnings, updating resources, clearing caches, and confirming the result in browsers. Keeping an audit trail prevents a temporary launch problem from becoming permanent and helps separate a newly introduced fault from a third-party issue that was already present.
Run a Webyzer analysis of your highest-traffic Australian domain today. Identify the first active mixed-content resource, correct its source, and verify the repaired page in a second browser. Then make that confirmed check part of every release before publishing new pages or campaigns.
