Secure Your Website with HTTPS: Paris Guide
A shop owner near Passy emailed me in February: her business website, online for four years, now showed "Not secure" right next to the address in Chrome. She thought she'd been hacked. In reality, no SSL certificate had ever been installed, and browsers have simply grown far stricter about it over the last couple of years. Switching to HTTPS isn't a technical detail reserved for big sites anymore: it's the bare minimum for a visitor to fill out a form or place an order without a second thought.
Published on 4 Aug 2026 · Website maintenance in Paris
It's the first thing a customer notices, often without even realising it: the browser's address bar. A closed padlock, an "http" that's quietly become "https": these details look tiny, but they decide in a fraction of a second whether someone keeps reading a page or closes the tab. For a Paris tradesperson, a small firm or a shop that lives off its contact form or quote requests, that isn't cosmetic. It's revenue.
What HTTPS actually protects, and what it doesn't guarantee
Technically, HTTPS encrypts the connection between a visitor's browser and the server hosting the site. In practice, that means if someone intercepts traffic on a public café or station Wi-Fi, or even on a poorly configured home router, they can't read what's being sent in plain text: login credentials, the content of a contact form, the details typed into a checkout page. Without HTTPS, that data travels as plain text, readable by any interception tool running on the same network.
What HTTPS does not guarantee is the honesty of whatever site sits behind that padlock. A Let's Encrypt certificate is free and issued automatically within minutes to anyone who owns a domain name, with no verification of the business's identity whatsoever. A phishing site impersonating a bank or a courier company therefore shows a perfectly valid padlock too. The padlock says "this connection is encrypted"; it never says "this site can be trusted". I've covered how to spot real scams elsewhere, including ones impersonating official technical support: the logic is the same, a reassuring logo or icon never proves an identity.
Why it's become non-negotiable in 2026
Chrome, Firefox and Edge now display an explicit "Not secure" warning as soon as a page served over http:// contains a form, and the alert gets more aggressive still if that form asks for a password or a card number. A visitor who sees that message before even reading your page assumes something is wrong and closes the tab without stopping to find out why. Google has confirmed since 2014 that HTTPS is a ranking signal; on its own the effect is modest, but by 2026 nearly every competing site is already secure, so it's the missing padlock that stands out, not its presence.
The real blocker often shows up at the third-party tool level: payment modules like Stripe or PayPal, booking widgets, some reservation plugins simply refuse to load on a page served over http. The quote form stays visible, but the submit button stops working, or the payment module throws a silent error the site owner only discovers when a client complains they never got a reply.
Getting a free certificate with Let's Encrypt on OVH, IONOS or o2switch
The three main hosts my Paris clients use all offer Let's Encrypt for free, built directly into the customer dashboard. The general logic is the same everywhere, even if the exact button location changes from one host to the next: go to the section covering the domain or web hosting, look for a heading called "SSL/TLS certificates" or simply "SSL", then enable the Let's Encrypt option for the domain in question. Activation usually takes anywhere from a few minutes to a few hours, depending on the host, while the certificate is generated and the web server reloads its configuration.
The real advantage of Let's Encrypt, beyond being free, is automatic renewal: the certificate is valid for 90 days, and the host regenerates it itself before it expires, as long as the domain keeps pointing to its servers. On a standard shared-hosting plan running cPanel or Plesk, the equivalent feature is usually called AutoSSL and works on the same principle. So in most cases, once it's been set up correctly the first time, there's nothing left to monitor.
The WordPress-specific settings
WordPress doesn't automatically switch to HTTPS the moment the certificate goes live on the hosting side. Two approaches work well. The first is installing a dedicated plugin such as Really Simple SSL, which detects the certificate, forces visitors onto the https:// version and rewrites most internal links in the database automatically. The second, more manual route, is going to Settings → General and changing both the "WordPress Address (URL)" and "Site Address (URL)" fields from http:// to https://, then saving.
Either way, one step remains essential: fixing mixed content. A site built a few years ago often has images, logos or embedded videos whose address was hard-coded with http:// at the time it was set up. Once the site is on https, those resources stay blocked or flagged as insecure by the browser, even though the rest of the page works fine. A database search-and-replace plugin, or a WP-CLI command, fixes those addresses in one pass instead of page by page.
The HTTP to HTTPS redirect: the step that gets forgotten
Turning on the certificate isn't enough to make the http:// version of the site disappear. Without an explicit redirect, both addresses stay live in parallel: an old link shared on social media, a page Google indexed before the switch, or a bookmark saved by a client still point to http:// and still show the "Not secure" warning, as if nothing had changed. That's exactly what happened to the shop owner near Passy: the certificate genuinely existed, nobody had simply forced the redirect.
The fix happens at the server level, through a rule in the .htaccess file or a dedicated toggle in the hosting dashboard, which automatically 301-redirects every http:// request to its https:// equivalent. Skip this step and all the previous work is wasted for the half of visitors still arriving via the old address, and Google may index both versions as separate pages, which dilutes your search visibility rather than improving it.
HSTS, in one honest sentence
HSTS tells browsers to always require https:// for your domain, even before the first request, which closes one more security gap, but if you enable it before confirming everything genuinely works over HTTPS, a configuration mistake becomes very hard to undo quickly, since browsers cache that requirement for several weeks.
How to verify it's actually been done properly
Open the site in a private window to avoid browser caching, and check that the padlock shows with no warning triangle next to it. Clicking it should show a certificate matching the right domain name, issued recently by Let's Encrypt. Next, press F12 to open the browser console and reload each key page: any resource still loading over http:// shows up as a "mixed content" warning in the console tab. A free tool like SSL Labs (ssllabs.com/ssltest) grades the whole configuration in a couple of minutes. Finally, deliberately type the old http:// address into the address bar: it should redirect automatically to https://, and test the contact or quote form end to end to confirm it actually submits.
What commonly breaks after switching to HTTPS
Mixed content remains the most common issue: images, fonts or scripts still called over http:// that show up crossed out or blocked, depending on the browser. Next comes the redirect loop, usually flagged as "ERR_TOO_MANY_REDIRECTS", which happens when the WordPress plugin and the host both try to force a redirect with conflicting rules. Google Search Console also needs a new property for the https:// version of the site, with a new sitemap submitted, otherwise search tracking ends up split in two. Third-party widgets, like a booking module or a chat widget whose embed code was copied years ago with a hard-coded http:// address, sometimes stop loading silently. And in the first few hours after the switch, it's not unusual for a client to report a certificate error on mobile while the new certificate finishes propagating.
What it realistically costs if someone else does it
The certificate itself never costs anything, Let's Encrypt is free with every serious host. What gets billed is the time spent setting it up and checking it. On a recent, well-structured WordPress site, budget €60 to €100 for activation, the redirect and fixing mixed content. On an older site, with addresses hard-coded across many pages or a custom theme, it's closer to €120 to €200, including page-by-page checking. That compliance check is also part of what I go through in a website maintenance contract in Paris, precisely so a certificate doesn't quietly expire or a redirect doesn't break without anyone noticing. For a brand-new site, HTTPS should be built in from day one as part of a website design project in Paris rather than fixed afterwards. And if the site is already ageing on other fronts, a full website redesign in Paris lets you handle HTTPS alongside everything else instead of patching old code; I've written separately about when it's worth redesigning an existing site rather than fixing it piece by piece.
Frequently asked questions about HTTPS and website security
Is a Let's Encrypt SSL certificate really free?
Yes, completely free and renewed automatically every 90 days by most French hosts such as OVH, IONOS or o2switch. The real cost is the time it takes to install and check it properly, especially on an existing site with mixed content to fix.
Does the padlock icon mean a website is trustworthy?
No. HTTPS only guarantees that the connection between the browser and the server is encrypted, not that the site or its owner are honest. Let's Encrypt certificates are automatic and free, so scam and phishing sites display a perfectly valid padlock too.
How do I know if my site has a mixed content problem?
Open the page in a private window, press F12 to open the browser console, then reload: any resource still loading over http:// shows up with a "mixed content" warning. A free tool like SSL Labs can also check the whole certificate configuration at once.
Should I turn on HSTS right after switching to HTTPS?
No. Wait until you've confirmed every page, form and resource actually works over HTTPS, because HSTS makes browsers remember that requirement for several weeks: a configuration mistake then becomes hard to undo quickly.
Want me to check whether your site is genuinely secure over HTTPS, with no mixed content and no forgotten redirect? Call or message me at 07 66 84 52 57, by phone or WhatsApp. I'll look at your site live and tell you exactly what needs fixing.
