Website Security for Business Owners: SSL to Backups
SSL certificates now last 200 days and Chrome is making HTTPS the default. A practical guide to updates, backups, login security and recovering from a hack.
Website security is the set of measures that protects your site, your visitors' data and your domain's reputation from unauthorized access, malicious code and data loss. For a typical business website, a solid baseline has five layers: auto-renewing SSL, disciplined updates, backups that follow the 3-2-1 rule, MFA-protected logins and continuous monitoring.
Fall 2026 turns website security into a calendar item. Since March 15, 2026, newly issued SSL certificates are valid for 200 days at most, so the first certificates issued under that rule expire around the end of September and early October. Google has also announced that starting with Chrome 154 in October 2026, Chrome will warn users before they open a public site that doesn't support HTTPS.
Attackers are moving faster, too. According to Patchstack's 2026 report, researchers found 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase over the previous year. For heavily exploited flaws, the median time to mass exploitation was just 5 hours. Verizon's 2026 Data Breach Investigations Report adds that 31% of breaches now start with vulnerability exploitation, overtaking stolen credentials for the first time in the report's 19-year history.
This guide is written for business owners without an in-house technical team. You won't need to write code, but you will know exactly what to ask for and who should do it. If you also run a mobile app, our mobile app security guide covers data protection on that side.
What this guide covers
- Why website security is a business issue
- Common attacks in plain language
- SSL certificates: the 2026 rule changes
- Update discipline: where most attacks get in
- Backup strategy: the 3-2-1 rule
- Login security: passwords, MFA and permissions
- Security headers, WAF and monitoring
- If your site gets hacked: the first 72 hours
- Who should own website security maintenance?
- Website security checklist for site owners
- Frequently Asked Questions
Why website security is a business issue
A successful attack rarely looks like "the site is down." Most attackers would rather use your site quietly than break it: they inject spam links, redirect mobile visitors to other sites or host phishing pages on your server. Google, your customers or a national security team may notice before you do.
Weak website security hurts a business in three concrete ways:
- Search visibility: Google flags hacked or harmful pages in the Search Console Security Issues report. Those pages can show a warning label in search results or a full-page browser warning. Once you clean up, Google says a review can take several days or weeks.
- Blocklisting: Browsers and security vendors block pages that spread malware or phishing. National teams do the same: in Turkey, the national cyber incident response center USOM publishes a list of malicious addresses that many organizations load into their firewalls, so a compromised company site can become unreachable from a client's office network.
- Legal obligations: The names, phone numbers and emails your contact form collects are personal data. Under Article 33 of the GDPR, controllers must notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. Turkey's data protection board applies the same 72-hour limit under KVKK.
Attack volume also follows geopolitics. Cloudflare's H1 2026 DDoS threat report shows Turkey climbing to the #3 most-attacked country in Q2 2026, in the run-up to the NATO Summit in Ankara.
Common attacks in plain language
Most attacks aren't targeted. Automated bots scan the internet and try every site where they find a plugin with a known flaw or an admin panel with a weak password. That's why "my site is too small to matter" doesn't hold up: bots care about the vulnerability, not the size of your business.
| Attack | What it does | Warning signs | Core defense |
|---|---|---|---|
| Plugin or theme exploit | Uses a known flaw in an outdated component to get in | Unknown admin accounts, modified files | Regular updates, delete unused plugins |
| Brute force and stolen passwords | Bots try thousands of passwords or reuse leaked credentials | Failed login alerts, unfamiliar sessions | Strong passwords, MFA, login attempt limits |
| Malicious code and spam injection | Adds hidden links, fake product pages or redirect code | Foreign-language spam titles under your domain in Google | File change monitoring, Search Console |
| Phishing page hosting | Plants a fake bank or courier login page on your server | Abuse complaints from your host, blocklisting | Updates, file monitoring, restricted permissions |
| DDoS | Floods the site with fake traffic until it's unreachable | Sudden slowdown or full outage | CDN, WAF, DDoS protection at the host |
| Supply chain (third-party scripts) | An external script your site loads gets compromised | Odd redirects for only some visitors | Script inventory, remove what you don't need |
| Form and comment spam | Bots flood forms and damage your inbox and sender reputation | Junk submissions, email deliverability problems | Bot protection, server-side validation |
The supply chain risk has a well-known example. The domain of polyfill.io, a service used to support older browsers, changed hands in February 2024. As Cloudflare reported, in June 2024 the service began injecting malicious JavaScript that redirected visitors under certain conditions. Site owners who loaded that script were affected without changing anything on their own servers.
Application-layer flaws such as SQL injection and XSS matter most for custom software. This guide focuses on the layers a site owner can track; for the application side, the standard reference is the OWASP Top 10.
SSL certificates: the 2026 rule changes
An SSL (technically TLS) certificate encrypts traffic between the browser and your site and confirms that visitors reached the real site. The "https" in the address bar is the visible sign. In 2026, two major changes landed in the same year.
HTTPS is now the default expectation
According to Google's HTTPS by default announcement, Chrome 147 turned on "Always Use Secure Connections" for Enhanced Safe Browsing users in April 2026. With Chrome 154 in October 2026, the setting becomes the default for everyone. Visitors who try to open a public site without HTTPS will first see a warning they have to click through.
The same announcement puts HTTPS adoption on public sites at roughly 97% to 99%, depending on the platform. If your site still loads over HTTP, you're in a small minority, and a warning screen will be the first thing visitors see.
Certificate lifetimes are shrinking: 200, 100, 47 days
The CA/Browser Forum, the body where browser makers and certificate authorities set the rules, passed Ballot SC-081v3 to cut certificate lifetimes in three steps:
| Effective date | Maximum certificate lifetime | Domain validation reuse period |
|---|---|---|
| Before March 15, 2026 | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
Let's Encrypt, the free certificate authority, is moving even faster. Under its published roadmap, the default certificate lifetime drops from 90 to 64 days on February 10, 2027, and to 45 days on February 16, 2028.
The practical takeaway: manual certificate renewal is no longer sustainable. Confirm that automatic renewal (via the ACME protocol) is enabled in your hosting panel and set up monitoring that alerts you 14 days before expiry. If you pay for an annual certificate plan, the certificate itself still has to be reissued at least once during that year, so ask your provider whether that happens automatically.
The padlock doesn't mean "safe site"
SSL protects data in transit, and that's all it does. A hacked site can still show a valid padlock, and most phishing pages use HTTPS too. A certificate is one part of website security; it won't fix a server vulnerability, a weak password or a missing backup.
Three SSL details that often get missed:
- Mixed content: Images or scripts loaded over HTTP on an HTTPS page trigger browser warnings or get blocked.
- Redirect every variant: www and non-www, HTTP and HTTPS versions should all 301-redirect to a single HTTPS address.
- HSTS header: Tells browsers to open your site over HTTPS only, closing the brief HTTP window before the redirect.
For most business sites, a free domain-validated (DV) certificate is enough. OV and EV certificates don't strengthen encryption; they only add organization verification.
Update discipline: where most attacks get in
According to W3Techs, WordPress powers 40.2% of all websites as of September 2026. That reach makes it the most efficient target for attackers, but for website security the problem rarely sits in the WordPress core itself.
In Patchstack's 2025 data, 91% of new vulnerabilities were in plugins and 9% in themes, while only 6 were reported in WordPress core. 46% of vulnerabilities had no patch available when they were publicly disclosed. The same report found that standard hosting defenses blocked only 26% of the attacks tested. Your host's firewall is a useful website security layer, but it doesn't replace updates.
Don't forget the server either. Per the official PHP support schedule, PHP 8.1 and older no longer receive security fixes, and security support for PHP 8.2 ends on December 31, 2026. If your site runs PHP 8.2 or older, plan the upgrade before year-end.
A practical update schedule
| Component | Recommended frequency | Note |
|---|---|---|
| Plugin or theme updates with security fixes | Same day, within 24 hours at most | Heavily exploited flaws get attacked within hours |
| Routine plugin, theme and core updates | Weekly | Test on a staging site first |
| Deleting unused plugins and themes | Monthly | Deactivated plugins still sit on the server as files |
| PHP and server software version | Check every 6 months | Put end-of-support dates in your calendar |
| Dependency updates in custom software (npm, Composer) | Monthly scan, immediately for critical flaws | Use automated vulnerability scanning |
| Third-party script inventory | Quarterly | Remove unused pixels and widgets |
The most common excuse for delaying updates is "it might break the site." The answer isn't to wait; it's to back up first, test on staging and be able to roll back within minutes if something goes wrong. If your site depends on dozens of plugins and maintenance never ends, our guide to moving from WordPress to a custom-built site compares your options.
Backup strategy: the 3-2-1 rule
Backups are your last line of website security when every other measure fails. In its backup guidance for small businesses, the US Cybersecurity and Infrastructure Security Agency (CISA) recommends the 3-2-1 rule:
- 3 copies: Your live data plus two backups.
- 2 different storage types: For example, a server disk and cloud storage.
- 1 copy offsite: At least one copy outside the infrastructure your site runs on.
CISA also recommends encrypting backups, keeping an offline copy and regularly testing restores, with the goal of being able to roll data back at least seven days. That threshold matters because an infection often sits unnoticed for days, which means your most recent backup may be infected too.
Your host's backup isn't your backup
Many hosting plans include automatic backups, and that's a good start. But those backups usually live with the same provider as your site. If your account gets suspended, a billing dispute escalates or an attacker gains panel access, you can lose the site and its backups at the same time. Count the host's backup as one of your three copies; the offsite copy should be under your own control.
Backup plan by site type
| Site type | Database backup | File backup | Retention |
|---|---|---|---|
| Rarely updated company site | Weekly and after every content change | Weekly | At least 30 days |
| Blog or news site | Daily | Weekly | At least 30 days |
| E-commerce store | Hourly or continuous | Daily | At least 90 days |
| Site with memberships or bookings | Hourly or continuous | Daily | At least 90 days |
Treat this table as a starting point. The real test is one question: "Can my business absorb losing a day of data?" For a store that takes orders, a lost day of transactions costs far more than a lost day of edits on a brochure site.
What goes into the backup matters too: the database, uploaded files and images, theme or code files, server configuration and a record of your DNS settings. Store configuration files that contain passwords or API keys in encrypted form. And the most important step: restore from a backup every quarter. You don't want to find out whether an untested backup works in the middle of a crisis.
Login security: passwords, MFA and permissions
Vulnerability exploitation may have taken the top spot in 2026, but stolen or guessed passwords remain the easiest way in. Anyone who logs into your admin panel doesn't need to find a flaw at all.
Core rules:
- Turn on MFA for every admin account. CISA's MFA guidance names phishing-resistant FIDO/WebAuthn methods (hardware keys, passkeys) as the strongest option, while stressing that any MFA beats no MFA. Where possible, choose an authenticator app over SMS.
- Eliminate shared passwords. Give your agency, each employee and every freelancer their own account instead of a shared "admin" login.
- Apply least privilege. A blog author doesn't need admin rights, and a content editor shouldn't be able to install plugins.
- Revoke access the day someone leaves. Former employees and past agencies are the most common owners of forgotten accounts.
- Limit login attempts. A temporary lockout after a handful of failed attempts stops brute-force attacks in practice.
- Use a password manager. It's the most practical way to share long, unique passwords safely across a team.
Don't forget your domain, DNS and email accounts
Website security goes beyond the admin panel. If someone takes over your domain registrar account, they can change DNS records and point both your website and your email to a server they control. Turn on MFA there as well, enable the domain transfer lock and auto-renewal, and make sure the domain is registered to an email address your company controls. A domain tied to a former employee's personal inbox is a silent risk.
Security headers, WAF and monitoring
Once prevention is in place, two questions remain: how much of an attack can you stop automatically, and how quickly will you know when something goes wrong?
Security headers
HTTP security headers are short instructions that tell the browser how to treat your site:
- Strict-Transport-Security (HSTS): Forces connections over HTTPS only.
- Content-Security-Policy (CSP): Limits where the page can load scripts and content from, which makes injected malicious scripts much harder to run.
- X-Frame-Options or frame-ancestors: Prevents other sites from secretly embedding yours in a frame.
HSTS and frame headers are quick to add. CSP needs careful testing because you have to list every source your site loads. You can check your current setup in seconds with Mozilla's free HTTP Observatory.
WAF, CDN and DDoS protection
A web application firewall (WAF) filters known attack patterns before they reach your server, and paired with a CDN it also absorbs DDoS traffic. Automation is essential here: in Cloudflare's report, 90.60% of network-layer DDoS attacks ended in under 10 minutes. No person can spot an alert and respond in that window.
A well-configured CDN often makes the site faster as well. Our Core Web Vitals guide explains how to set up the speed and infrastructure layers together.
Monitoring: see problems before your customers do
Three free or low-cost monitoring layers cover the website security basics for most business sites:
- Uptime monitoring: Sends an email or SMS alert within minutes when the site goes down.
- Google Search Console: Verify your site and enable email notifications; this is where Google warns you about security issues.
- Certificate expiry alerts: On a 200-day cycle, automatic renewal can fail silently, so get an alert at least 14 days before expiry.
Online stores need one more layer: scripts on the payment page. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1, effective since March 31, 2025, call for an inventory of payment page scripts and detection of unauthorized changes. Merchants that fully outsource card data handling to a validated provider (SAQ A) are exempt from those two requirements, but they must confirm their site isn't susceptible to script-based attacks.
If your site gets hacked: the first 72 hours
Typical signs of a hacked website:
- A
site:yourdomain.comsearch in Google shows unfamiliar, often foreign-language product or pharma titles - Redirects that happen only on mobile, or only for visitors arriving from Google
- Admin accounts you don't recognize, or core files with recent modification dates
- A security warning from Search Console, or a spam or abuse notice from your host
- An unexplained traffic drop or a sudden spike in server resource usage
If you see any of these, follow this order:
- Stay calm and preserve evidence. Don't start deleting files; take a copy of the current state first. You'll need it to understand how the attacker got in.
- Cut off access. Put the site in maintenance mode, change every admin, hosting, FTP and database password, and end all active sessions.
- Assess whether personal data was affected. If form entries, member data or order details leaked, the 72-hour breach notification clock under GDPR or KVKK starts when you become aware of the breach. Bring in legal counsel at this step.
- Restore from a clean backup. Choose the last backup from before the infection; this is exactly when several weeks of backup history pays off.
- Close the hole. After restoring, update plugins, themes, core and PHP. A site restored without fixing the entry point will get hacked again the same way.
- Request a review from Google. In the Search Console Security Issues report, describe what you fixed and request a review. After the cleanup, use our free site analysis tool to confirm your pages return valid status codes and that nobody has tampered with noindex or robots.txt.
- Check blocklists. If your domain was used for phishing, watch for browser warnings and entries on national malicious-link lists until they clear.
The whole process may not fit into one working day. Still, a business that handles the first 72 hours with a plan keeps both its legal deadline and its search visibility under control.
Who should own website security maintenance?
The most common website security failure isn't a lack of knowledge; it's a gap in ownership. The site owner assumes the host handles it, the host assumes the agency does, and the agency assumes the owner does. Here's a typical split:
| Task | Hosting provider | Site owner | Agency with a maintenance contract |
|---|---|---|---|
| Server hardware, network and physical security | Owns it | — | — |
| Server OS and PHP version | Depends on plan | Tracks it | Owns it |
| SSL setup and auto-renewal | Owns it on most plans | Verifies it | Owns it |
| CMS, plugin and theme updates | — | Can do it | Owns it |
| Offsite backups and restore tests | — | Can do it | Owns it |
| User accounts, MFA and permissions | — | Owns it | Supports |
| Domain and DNS account security | — | Owns it | Supports |
| Post-hack cleanup and closing the hole | Limited support | — | Owns it |
On shared hosting, the provider manages the server. On a VPS or cloud server, operating system updates usually fall to you or your agency. Having the word "security" in your contract isn't enough; assign a named owner for every row in this table, in writing.
Here's a scenario we see often, including with companies in Turkey: a manufacturer had its website built years ago by a freelancer, lost touch with them, and the admin password left with the developer. The site still runs on an outdated PHP version. The first job isn't a redesign; it's regaining access, taking a backup, closing vulnerabilities and then moving the site to a current stack. Our article on the signs it's time for a website redesign helps you judge whether your site has reached that point.
Website security checklist for site owners
Put this list in your calendar. Most items need no technical skills; for the rest, you just need to know who's responsible.
One-time setup
- Every HTTP and www variant 301-redirects to a single HTTPS address.
- SSL auto-renewal is on, and the expiry date is monitored.
- MFA is enabled on admin, hosting, domain and email accounts.
- There's no shared "admin" account; everyone has their own login with the right permissions.
- The domain transfer lock and auto-renewal are enabled.
- Encrypted, automatic offsite backups are running.
- Search Console is verified, with notifications turned on.
- Uptime monitoring and at least the HSTS header are in place.
Ongoing routine
- Weekly: Plugin, theme and core updates; confirm backups completed successfully.
- Monthly: Remove unused plugins and accounts; run a
site:search to spot spam pages. - Quarterly: Test a restore from backup, review third-party scripts and rescan security headers.
- Yearly: Check PHP and server software support dates; review responsibilities in your hosting and maintenance contracts.
Frequently Asked Questions
Is a free SSL certificate good enough?
For most business sites and blogs, yes. Free domain-validated (DV) certificates such as those from Let's Encrypt provide the same encryption strength as paid ones. Paid OV and EV certificates add organization verification and support, not stronger encryption.
How often should I back up my website?
Frequency depends on how much data you can afford to lose. A rarely updated company site may be fine with weekly backups, while sites that take orders or bookings should back up the database hourly or continuously. In every case, keep at least one copy outside your hosting provider and make sure you can roll back at least seven days.
How do I know if my website has been hacked?
The most common signs are foreign-language spam pages in a site:yourdomain.com Google search, redirects that only happen on mobile, admin accounts you don't recognize and security warnings from Search Console. A spam or abuse notice from your hosting provider is another serious signal.
Is WordPress insecure?
WordPress core is actively maintained and has few vulnerabilities. In Patchstack's 2025 data, 91% of new vulnerabilities were in plugins and 9% in themes, with only 6 reported in core. Your real risk depends on how many plugins you run and how consistently you update them.
Is a security plugin enough on its own?
No. Security plugins and hosting firewalls are useful layers, but in Patchstack's testing, standard hosting defenses blocked only 26% of attacks. Without updates, MFA, offsite backups and monitoring, no plugin can protect a site by itself.
Why does my SSL certificate need renewing so often now?
Under a CA/Browser Forum ballot, certificates issued from March 15, 2026 are valid for a maximum of 200 days. That limit drops to 100 days on March 15, 2027, and to 47 days on March 15, 2029. Without automatic renewal, an unnoticed expiry and a browser warning for your visitors are only a matter of time.
Isn't my hosting provider responsible for website security?
Hosting providers are generally responsible for server infrastructure and network security. On shared hosting, CMS, plugin, user account and content security usually falls to the site owner or the agency that maintains the site. Spell out that split in writing in your contracts.
Does website security affect SEO?
Yes. Google can label hacked or harmful pages with warnings in search results, and a review after cleanup can take days or weeks. Starting in October 2026, Chrome will also show a warning by default before users open public sites that don't support HTTPS.
Website security isn't a one-time setup; it's a routine tied to your calendar. Automating SSL, making updates a weekly habit, following the 3-2-1 backup rule and enabling MFA on every account take your site off the list of easy targets that automated bots look for.
In our web design and web software development projects, we plan security as part of the infrastructure decisions, not as a layer added after launch. To review your current site's security together, get in touch.
Need professional help with this?
Talk to our team about your project — same-day response, free quote.


