After switching the site to HTTPS, the product page map is blank and live chat does not pop up: should I check the certificate or the page resources first?

When a client says the address bar has no padlock, the product page map is blank, and live chat does not pop up, the cause is often not a misinstalled certificate. It is usually active mixed content: iframes, scripts, or API endpoints still starting with http inside the page. Based on 2026 delivery experience, troubleshoot by resource source first, then decide whether to change addresses, replace sources, or apply a transitional fix. A certificate only covers the domain layer; the padlock appears only when all page resources load over https.

Why does the page still show insecure after the certificate takes effect?

When a site enables https, it encrypts the connection between the browser and the server. A single page often pulls resources from multiple sources: images in the template, legacy assets from the backend, third-party live chat scripts, map iframes, and analytics code. If even one of them is still http, the browser treats the whole page as mixed with plaintext, and the address bar padlock is downgraded or replaced by a warning. The certificate is not broken; the page is not clean.

The severity of handling depends on the type: for passive content such as images, audio, and video, the typical result is blocked or downgraded loading; for active content such as scripts, stylesheets, iframes, and form endpoints, the typical result is outright refusal to load, which shows up as live chat not opening, a blank map, or no analytics data. Mixed content is not just cosmetic; it directly affects functionality.

• Passive mixed content: images, audio, video, and ordinary external resources; typical result is blocked loading or incomplete display;
• Active mixed content: scripts, stylesheets, iframes, and form submission endpoints; typical result is outright non-execution;
• Hidden mixed use: the page is https, but API requests are hard-coded to http; visitors see no warning, yet functionality works intermittently.

Delivery scene: troubleshooting by resource source is faster than checking page by page

In one project, the client had just switched to https and allowed only two days for acceptance. The site had over two hundred pages. Live chat and maps were provided by third parties the client had contracted, while templates and the backend were with us. Instead of editing page by page, we first pulled the network list from the console and filed issues into four categories: hard-coded in templates, backend uploads, external-site references, and third-party embeds. We batch-replaced template and database items, and separately listed third parties for the client to confirm https addresses. Template issues often clear within half a day to one day (experience range). When third parties are slow to respond, acceptance is often delayed by one to three working days (typical range), so this needs to be written into the responsibility boundary in advance. In the end, the page padlock returned, and the client also accepted the delivery wording that third-party addresses are not guaranteed by us alone.

Troubleshooting order follows change cost from low to high:

1. Absolute URLs hard-coded in templates: header logo, footer QR code, default share image; one change applies site-wide, so handle these first.
2. Legacy images uploaded through the backend: early assets may store full http paths; batch-replace them or make the program output the current protocol.
3. External images in rich-text body content: content pasted from WeChat public accounts, old editors, or external sites often still has http image URLs.
4. Third-party embeds: live chat, analytics, maps, and video players; confirm separately whether the provider offers an https address.
5. API and form endpoints: form submission endpoints and payment callbacks in backend settings are the easiest to forget when switching to https.

For each category, note who is responsible for the change: templates and backend uploads belong to the site builder; external images and third-party embeds usually require the client to contact the provider or replace the asset. If the boundary is unclear, the work most easily drags into repeated revisions.

Self-check and acceptance: write items to the point where they can be checked off

Self-checks should not rely on feel. Open the console and network panel in developer tools, filter non-https requests, and most issues can be located. Then spot-check mobile devices and third-party browsers; some in-app browsers block more strictly. Based on common practice in 2026, writing acceptance criteria as checkable items is more reliable than writing 'the page is secure'.

• Address bar status: sample two or three pages each from home, product list, product detail, news detail, and contact us; all should show the padlock icon;
• Clean console: no mixed content warnings and no scripts rejected because of protocol;
• Key functions work: forms submit, live chat opens, maps display, and video plays;
• Redirects in place: http visits return a 301 to https with no redirect loop.

An easily overlooked issue is forcing only the home page to redirect while inner pages can still open over http. This partial redirect tends to split analytics and indexing, so acceptance should click each page category once, not just check the home page.

Treatment comparison: count first, then decide the plan

The same warning can call for very different treatments. Most projects only need address changes and redirect configuration, not a full site rebuild. The following experience ranges are based on common effort levels; actual effort depends on site size and the number of third-party dependencies, and no exact commitment is made.

• Option A: change addresses and add site-wide 301. Replace full http paths in templates and the database, and configure http-to-https 301 redirects. The change is small; common effort is about 0.5 to 2 person-days (experience range), suitable for self-built sites with resources mostly on the same site.
• Option B: redirect only the home page. Fast to implement; often live within one to two hours (typical range), but inner pages may still open over http, and analytics and indexing can split. Suitable for temporary emergencies, not long-term external operations.
• Option C: add CSP at the page head to force upgrade. This can automatically change some http resource requests to https, but if the other site has no https version, resources still fail to load. It is a transitional measure.
• Option D: replace sources and host centrally. Move images and video to storage that supports https, solving the external-link protocol issue at the root. Effort is usually on the order of several working days (experience range), suitable for sites with many assets and many cross-domain references.

Which path to choose depends on how many http resources remain and who controls them. If only three to five remain and all are in your own templates, Option A is usually enough. If dozens or hundreds remain and are scattered across third parties, Option D is often less work than fixing them one by one. Counting first and then deciding saves more time than deciding first and then hunting for problems.

When it applies and when it does not

Not every warning requires engineering work. The cases below should be viewed separately; a wrong judgment leads either to overinvestment or to a real problem being missed.

• Worth handling: public-facing corporate sites, pages that collect inquiry forms, pages with payment or login, and sites shown in bidding or promotional contexts. In these scenarios, address bar status affects visitor trust.
• Can be deferred: purely internal preview sites, temporary campaign pages, and test environments one or two days before launch, provided no external links are distributed and no ads are run. At that point, getting functionality working is more practical.
• No need to force it: in rare cases, a third-party resource truly has no https version and must be kept for business reasons. The common approach is replacement, static-image substitution, or local hosting, rather than repeatedly struggling with the certificate.

One more case should be stated in advance: if a site was originally http-only, switching the whole site to https will affect redirects, analytics code, and search platform site settings, which is broader than installing a certificate. A useful boundary sentence is: a certificate is the switch; mixed content is the wiring. Turning the switch on does not mean the whole line is connected.

Frequently asked questions

The certificate is issued, so why is there still no padlock in the address bar?

The certificate only handles domain-level encryption. When the page still contains http images, scripts, or iframes, the browser downgrades the indication. Check resource addresses first, then check the certificate chain and redirect configuration.

If only the map and live chat do not display, is that still mixed content?

Yes. Map iframes and live chat scripts are mostly active content, and browsers refuse to load them directly. Typical symptoms are blank areas, no pop-up, and no analytics data.

Images are http and everything else is https; does it matter?

Yes, handle it. Passive content is often blocked or downgraded, and what visitors see can differ from what crawlers see. The common fix is to change to https or use same-site relative paths.

After switching to https, do old http links still work?

They can work, but configure 301 redirects to https and avoid redirect loops. Returning 404 for old links directly loses external references and existing entry points.

What if a third-party resource has no https version?

First ask the provider for an https embed address. If unavailable, replace the asset, substitute a static image, or host it locally. Keeping an http embed long term leaves a continuing risk that the browser will block the functionality.