You can review your business website's security yourself in a single afternoon: WordPress updates, a backup, the domain registrant's contact data, a scan on moje.cert.pl and the report in Search Console. You don't need a developer or a new subscription for that — you need a list of checkpoints and one free afternoon per quarter. A site a contractor built for you a few years ago is not “set and forget”: plugins and the theme age, the domain has an expiry date, and the renewal invoice can land in an inbox nobody opens anymore. A hack rarely looks like a hack, either — more often it's a form that sends into the void, or foreign links on a subpage nobody monitors.
Below you'll find nine checkpoints of a quarterly review, a table to tick off, a worked example for the domain and a source behind every claim: the WordPress documentation, the hardening guide, the .pl registry run by NASK, CERT Polska and Google's help pages. At the end we show what the same area looks like when a system keeps watch instead of the owner's memory.
What happens when a website breaks quietly
A company site failure rarely shouts. The form still “sends”, but the e-mails never arrive; foreign links to pages you have nothing to do with appear on three subpages; the domain expires because the notice went to an old address. All three situations share one thing: there is no signal. A customer won't write “your form is broken” — they leave and call the next company on the list. How many inquiries disappear before anyone in the firm sees them is something we unpack in the analysis of why customers don't leave inquiries.
Our own numbers show the scale of “domain exists, website doesn't”. Among 16,592 Warsaw businesses whose websites we analysed (July 2026), 1,564 had a domain with no website running under it. That doesn't mean all those domains expired — sometimes the site vanished in a hosting migration or was never connected at all. It does show how easily the situation goes unnoticed: the firm operates, the Google listing lives on, and the one address a customer could visit simply doesn't work.
Where these numbers come from: we analysed public websites of Warsaw businesses in a given industry (July 2026); the share is counted against the sites that could be opened.
If your site was built years ago and nobody has looked at its forms or measurement since, the review is a good moment to check how Websites and stores are built today — a business site with a form and measurement from day one, not a photo gallery with no evidence anyone uses it.
WordPress: updates and a backup you can restore
The first line of defence is unglamorous: WordPress is updated regularly to address new security issues — the administrators' hardening guide says it outright (developer.wordpress.org). The simplest thing an owner can do is open the Updates tab in the dashboard and check whether versions from several months back are waiting there. The guide also notes that outdated plugins and software are a typical target of attacks — so the list of pending updates is itself information about risk.
Background updates since version 3.7
Since version 3.7 WordPress has had automatic background updates: minor security and maintenance releases install themselves without your involvement (wordpress.org). That closes part of the risk, but it doesn't cancel the review. The theme, the plugins and major releases remain — the part where a human decides, and where a contractor is sometimes needed once something stops being compatible after an update. The quarterly review exists precisely so these backlogs don't grow for a year.
The backup: what to settle with your contractor
The WordPress documentation puts it practically: back up your site before updating, so you can restore it if anything goes wrong. Hence a concrete task for your contractor, worth sending once and keeping the answer in writing: where the backup lives, how often it's created and who is able to restore it. A backup nobody has ever restored isn't a safeguard — it's just a file someone once configured.
Two checks in the dashboard: accounts and plugins
The hardening guide describes typical vulnerabilities and basic protective measures; a fair part of them needs a server administrator. But there are two checks an owner can do alone in the dashboard, without touching code — and both fit into a quarterly review.
Administrator accounts and passwords
Open the Users tab and read the list. You're looking for accounts nobody recognises: an “admin” left by a contractor years ago, a former employee's account, a test account. Every extra administrator account is another place where someone can guess a password. The hardening guide reminds you what strong passwords are for: hard for other people to guess and resistant to a brute force attack. If an account has no reason to exist — delete it or lower its permissions.
Plugins nobody uses
The second tab: Plugins. The guide's rule is unambiguous — keep your plugins updated, and a plugin you're not using shouldn't be deactivated but deleted from the system. An inactive plugin is still files on the server: if it has a known vulnerability, it sits there like an unused door everyone forgot about. The same guide advises against installing plugins and themes from untrusted sources — stick to the official WordPress.org directory or known authors. While you're there, review the themes list too: one active and one fallback usually suffice; the rest is ballast.
If you're wondering where the data customers type into your forms physically ends up, and who can access it along the way, read Automation and GDPR: where your customer data physically ends up.
The domain: registrant e-mail and renewal without waiting
NASK, which runs the .pl domain registry, recommends two things that cost nothing (dns.pl). First: the registrant's contact data — the e-mail address in particular — must be current, and you report every change to the registrar as it happens. Second: if the domain went unpaid and entered the BLOCKED state, you can still renew it with your registrar, but NASK says it plainly — do it immediately, don't wait until the last day of that state.
The registrant's e-mail is the most underrated point of website security. If the inbox has expired or belongs to a former employee, no notification will ever reach you about the expiry — first the site disappears, then the company mail, and after the deadline someone else can take the domain. So in the quarterly review you check two things in the registrar's panel: which e-mail receives the notifications and how many days are left in the paid period.
A worked example on assumed numbers — plug in your own dates. Your review is on 1 January; the domain is paid up to 15 March. That leaves 73 days to expiry (January: 30 days counting from 2 January, February: 28, March: 15), while your next quarterly review is roughly 90 days away. The conclusion: you renew at the current review, not at the expiry date — the buffer protects you when a payment stalls for a week or a dispute drags on.
An outside view: moje.cert.pl
Before you judge anything, it's worth seeing your domain the way an attacker sees it — from the network, not from the dashboard. CERT Polska describes moje.cert.pl as a tool that lets you check free of charge how the infrastructure assigned to a domain looks from the network's perspective (cert.pl). In practice you get an outside picture: exposed services, vulnerabilities and misconfigurations that — as CERT writes — administrators are often unaware of.
The scale is concrete: according to CERT Polska, moje.cert.pl has so far been used to check over 3.5 million domains, subdomains and IP addresses, identifying more than 750,000 vulnerabilities and misconfigurations. Large organisations take the tool seriously, and within a quarterly review of a company site it fits into a few minutes: you check your own domain and read the result.
One caveat: this is a complementary view, not a replacement. moje.cert.pl won't log into your WordPress dashboard for you, won't remove an old plugin and won't renew the domain — which is why in the review table it's one of the points, not the whole table.
Google's signal: the report in Search Console
Google maintains the Security Issues report in Search Console. If a Google evaluation determines that your site was hacked or exhibits behaviour that could harm a visitor or their computer — phishing pages or unwanted software, for example — the report shows Google's findings (Search Console Help). The effect is tangible: pages with detected issues are marked with a warning symbol in search results, and before clicking through, the user sees a message about why they shouldn't. A customer who sees that warning next to your company's name doesn't click — and doesn't come back.
For an owner, this report is often the first official signal that something happened: a customer won't report a foreign link, but Google will. So in the review you check two things: whether the site is verified in Search Console at all (if nobody in the firm knows — that's the first task to tick off) and whether the report is empty. After a fix, the site still needs a request for a review — the Google help pages describe this too.
It's worth wiring the website's numbers into the company's numbers at this point: where inquiries come from and what they cost. How to set that up is covered in Analytics and BI, and the numbers an owner actually looks at are discussed in reporting automation.
The quarterly review table
The whole review closes into one table. The “who does it” column matters most: some points you'll handle yourself in minutes, others you delegate to the contractor — what counts is that every point has an owner and a date.
| Review point | Where to look | Who does it | Status |
|---|---|---|---|
| WordPress, theme and plugin updates | dashboard → Updates | you or the contractor | ok / to do |
| Backup and a restore test | hosting panel | the contractor | ok / to do |
| Admin accounts and unused plugins | dashboard → Users, Plugins | you | ok / to do |
| Registrant e-mail and domain expiry date | registrar's panel | you | ok / to do |
| Outside scan of the domain | moje.cert.pl | you | ok / to do |
| Security Issues report | Search Console | you | ok / to do |
Print the table or copy it into a note — after four reviews a year you have a history: what broke, who fixed it and how long it took.
Do it yourself in one afternoon
The order is simple and needs nothing beyond a browser and a calendar:
- Walk the table top to bottom. At each point, tick “ok” or add one sentence: what you see and since when.
- Collect the three most urgent items into one message to the contractor — specifics instead of “fix the security”.
- Settle once and for all: where the backup lives, how often it's created and who can restore it.
- Check the registrant's e-mail and the domain expiry date in the registrar's panel; if less time remains to expiry than to your next review — renew now.
- Put the next review in the calendar for three months out. The ritual matters more than the tool.
Three example tasks for the contractor, so the message doesn't hang unanswered:
- “plugin X has been waiting for an update since March — update it and check compatibility with the theme”;
- “delete the administrator account named Y — nobody recognises it”;
- “show me on a test page how to return to this week's backup version”.
After the first pass, later reviews get shorter: the account list is already lean, the backup works, and you're just refreshing dates. By the fourth review of the year it's usually less than half an afternoon.
What it looks like when a system watches the site
A quarterly review closes the risk you can plan for: overdue updates, redundant accounts, a domain without a buffer. It won't catch a form that stopped sending on a Thursday evening — a quarter is a very long time in that failure mode. So the other half of the picture is a daily check that doesn't depend on the owner's memory:
Daily check:
- 01system opens the site
- →02tests the form
- →03detects an error
- →04sends a signal
- →05creates a task for the contractor
- →06logs an entry
In this setup the human decides one thing: what happens after the signal — whether it's a task for today or a report to the contractor. A system doesn't give one hundred percent protection against hacking, because no such thing exists; it gives what a calendar reminder every quarter cannot — certainty that the form works today, not that it worked whenever it was last checked. At Aura, this view of the site sits next to the rest of the company: Admin panels gather leads, content and statistics in one place, SEO and maps look after visibility in Google where customers actually search, and Integrations wire the form, the calendar and the CRM into one flow so the connection doesn't quietly fall apart.
Before you automate anything, read when it's not worth implementing anything and about the five situations where we advise against starting.
Frequently asked questions
How often should I run this review?
Once a quarter is enough to sort out what's plannable: updates, accounts, the domain, the backup. It doesn't replace a daily check of the form and availability — a form can break the day after a review — so the two rhythms complement each other rather than exclude each other.
Won't WordPress updates break the site?
The risk exists, and that's exactly why the WordPress documentation recommends a backup before updating. The safe order is one: backup, then updates, then checking the form and the site on a phone. Since version 3.7, minor security releases install on their own in the background anyway.
What should I do when Search Console shows a security issue?
Don't panic and don't delete the site. The report shows what Google's evaluation found, together with a description of the problem; pages with issues are marked in search results with a warning symbol. The practical order: a backup, a message to the contractor with the specifics from the report, the fix, and only then a request for a review.
Does moje.cert.pl replace the whole review?
No. It's an outside view: services, vulnerabilities and misconfigurations visible from the network. It won't check your WordPress dashboard, user accounts or the domain's expiry date — which is why it's one point in the review table, not the whole table.
Who should make the backup: me or the contractor?
Usually the contractor or the hosting provider, but the owner should know three facts: where the backup lives, how often it's created and who can restore it. If nobody can answer the third one, you have a ready task for the next review.
Is a quarterly review protection against hacking?
Complete protection doesn't exist, and nobody honest promises it. A review lowers the risk: updates close known holes, unused plugins and accounts get removed, the domain gets a renewal buffer. The rest is fast detection: the Search Console report, an outside scan and a daily check of the form.