Browsers block part of your page: the http-file fix
A family dental office moved its website to https years ago, and the padlock showed in the address bar, so everyone assumed the job was done. But the home page still pulled four files over plain http://: the web font, one stylesheet, the slider script and the online-booking widget. Browsers refuse to load scripts and stylesheets over http on an https page, and they do it silently - no warning bar, no error the owner would ever see. Visitors got a plain-font page, a slider stuck on its first photo, and an empty box where "Book online" should have been. Here is what was found, what changed, and how long it took.
| File on the home page | Before | After |
|---|---|---|
| Web font (stylesheet) | http:// link - blocked, so the page fell back to a plain system font | https:// - the brand font shows again |
| Theme stylesheet | http:// address saved in the theme settings years ago - blocked, spacing and buttons unstyled | https:// - layout as designed |
| Photo slider script | http:// - blocked, slider frozen on the first slide | https:// - slides rotate |
| Online-booking widget | http:// embed code pasted in 2019 - blocked, an empty box where patients book | re-pasted from the booking company's current https embed code - booking works |
| Result | Before, the padlock showed and the office saw nothing wrong on its own phone, which had the old files cached. New visitors got the stripped page. After, the Console shows no Mixed Content lines and the booking box loads on every browser. | |
What was wrong
When a site switches to https, links typed into the page, the theme settings or the database years earlier keep their old http:// address. The page itself is secure, so the padlock shows, but each of those files is asked for over an unencrypted connection, and browsers block scripts, stylesheets and embedded frames fetched that way. Images are usually retried over https, and simply go missing if that fails.
Before (in the page source): <link rel="stylesheet" href="http://fonts.example.com/css?family=Lato"> <script src="http://www.yourdomain.com/wp-content/themes/x/slider.js"></script> <iframe src="http://booking.example.com/widget?office=123"></iframe> After: <link rel="stylesheet" href="https://fonts.example.com/css?family=Lato"> <script src="https://www.yourdomain.com/wp-content/themes/x/slider.js"></script> <iframe src="https://booking.example.com/widget?office=123"></iframe>
How it was fixed
- List every blocked file from the Console on the home page and the other main pages (contact, booking, services).
- Files on your own domain: change http://yourdomain.com to https://yourdomain.com wherever it is stored. On WordPress that is one database search-and-replace (the free Better Search Replace plugin), run on a backup first; on Wix, Squarespace or Shopify it is the section or embed setting that holds the address.
- Files from other companies (fonts, widgets, booking or chat tools): switch the address to https, or re-copy the provider's current embed code, which is https today.
- Re-check the Console on each page in a private window, so nothing comes from the cache.
What it costs
I will send you the exact list for your site - each http file and the line that replaces it - free, and you can change them yourself. If you would rather I do it, it is a small fixed price, paid only after the Console shows no blocked files. No password shared: WordPress, Wix, Squarespace and Shopify all let you add a helper account and remove it when we are done. Usually under an hour, with nothing visible changing except the parts that were missing.
The office in this example is a composite built for this demo, not a real business; the blocked files and the fix are the ones found on real small-business home pages in October 2026. More before/after examples, and who I am: all demos.