Security
How we keep your website safe
A Send to Site website has no WordPress admin, no login page, no plugins and no database behind its pages, so the usual ways into a hacked website are not there. Changes are accepted only from the email addresses registered for your site. Each one is built on a separate copy, checked by code and by a reviewer that cannot write anything, and goes live only when you tap Publish.
Last updated
What an attacker finds on a Send to Site website
- No WordPress admin area
- No login page
- No plugins or themes to exploit
- No database behind the pages
What is there instead
- Static HTML pages on Cloudflare Pages, over HTTPS
- Changes only from registered, verified senders
- A record of every change in version history
Why sites get hacked
Why WordPress sites get hacked, and what a static site removes
The weak point of most WordPress sites is their plugins: 91% of the new WordPress security flaws found in 2025 were in plugins. A static site has no plugins, no login page and no database, so those ways in are gone.
Patchstack, a WordPress security company, counted 11 334 new security flaws in the WordPress ecosystem in 2025, 42% more than the year before. Themes had 9% of them. WordPress core had just six, all of them low priority. The figures are in its State of WordPress Security in 2026 report.
Timing is the hard part. Patchstack found that 46% of those flaws had no fix from the developer by the time they were made public, and that the most heavily targeted ones were typically attacked within hours, not days. A WordPress site is only as safe as its least-maintained plugin.
Being hacked costs more than a cleanup. Google can show "This site may be hacked" under your listing in search results, and browsers can show a warning page before your site even opens. Removing the label means cleaning the site and asking Google for a review, as its help page on sites labelled as dangerous explains.
Static does not mean untouchable. Once the usual ways in are gone, the real questions are who can change your site and what a change is allowed to do. The rest of this page answers both.
| The usual way in | On a typical WordPress site | On a Send to Site website |
|---|---|---|
| Plugins and themes | Code from many different developers, each part needing its own security updates | None. Your pages are finished HTML files. |
| The login page | A public login page that password-guessing bots try around the clock | No login page. Changes arrive by email from verified senders. |
| The database | Pages are built on the server from a database | No database behind the pages |
| Updates | A steady stream of core, theme and plugin updates, any of which can break a page | Nothing of that kind to patch |
Sender checks
Who can change your site
Only the email addresses registered for your site can ask for a change, and the email has to prove it really came from that address.
Registered addresses only
You tell us which email addresses may send changes: yours, and anyone on your team you choose. Mail from any other address is never acted on.
Your domain has to vouch for the email
DKIM, DMARC and SPF are records your email domain publishes so that mail servers can tell a genuine email from a forgery. Every change request has to be vouched for this way. A forged sender is refused.
Strangers get silence
An email from an address we do not know gets no reply at all. A person here is alerted instead.
Only your new words count
Quoted text from earlier emails is removed before any AI model reads your reply. An old instruction or a quoted article further down the thread is never acted on.
Every change, every time
How every change is checked before it goes live
Every change is made on a separate copy of your site and must pass automated checks, a read-only reviewer and a code check before it can go live. Then it waits for you.
- 1
A separate copy
The change is made on its own copy of your site, called a branch. Your live site is not touched while the work happens.
- 2
Automated checks
The copy is built and tested by automated checks, the same way every time.
- 3
A reviewer that cannot write
A separate reviewer reads the change and confirms it does only what you asked. It cannot write anything: if its copy changes at all, the job fails.
- 4
A code check for scripts and deletions
Any added script, iframe (a window onto another website), embed or tracker is blocked. So is any page that has been deleted or emptied.
- 5
You tap Publish
You get a preview link with Publish and Cancel buttons. Reply to ask for a revision. Nothing goes live until you tap Publish.
Every job also has a hard time limit, so a stuck job stops instead of running on. See the whole change process, step by step
Publish buttons
Links that cannot be reused
The Publish and Cancel buttons in our emails are signed, single-use links that name one exact change and expire.
- Signed. Each link carries a signature our system checks, so a made-up or edited link does not work.
- Named. A button can only publish or cancel the change it was sent for.
- Single-use. Once tapped, it stops working.
- Expiring. It stops working after a set time, even if nobody taps it.
So an old email, or one forwarded to someone else, cannot publish something else.
Send to Site to you
Your preview is ready
Have a look, then publish it or tell us what to change.
Each button is tied to this one change, works once and expires.
Your data and POPIA
Your data, your visitors' data and POPIA
There is no database behind your pages and no login to steal, and any change that would publish sensitive numbers or add a tracker is stopped.
No ID, card or bank numbers on a page
South African ID numbers, card numbers and bank account numbers are never put on a page. A request that would publish one is stopped.
No new trackers
Tracking scripts, embeds and third-party code are blocked by the code check, so a change cannot quietly add something that collects data about your visitors.
Nothing outside your website
Your domain, email, hosting accounts, social media accounts, payments and bookings are never touched. They stay under your control.
The Protection of Personal Information Act (POPIA) sets the rules for how South African organisations handle personal information. How Send to Site collects, uses and protects yours is set out in our privacy policy.
Version history
Version history and undo
Every change is recorded in version history, which is the audit log of what went live on your site and when.
A record of every change
The history is kept in git, the version control system software teams use to track every edit. Nothing reaches your site without leaving an entry.
An undo is one reply
Reply to the email about a change and ask for it to be undone. The undo is an exact reverse of that change, not a rough repair.
Archived, never deleted
Articles you decline are archived, not thrown away, so the record of what was proposed stays.
Limits, stated plainly
What we refuse, by design
Some requests are declined every time, because each one would put your site, your visitors or your accounts at risk. If yours is one of them, a person explains why.
- Add a tracking script, embed, iframe or third-party code. It slows the site and can leak visitor data.
- Delete or empty a whole page. Too easy to do by mistake from a short email.
- Put an ID, card or bank account number on a page. The request is stopped.
- Touch anything outside the website. Your domain, email, hosting, social media, payments and bookings stay with you.
- Redesign the whole site from one email. That is a design project, not a change.
- Guess. When the system cannot handle a request, it escalates, and a person responds within one business day.
We tested this on purpose before launch. We sent the system 20 deliberately unusual requests, among them defamatory text, a request to copy a competitor's design, a password reset and a South African ID number. Every one was handled correctly: declined, passed to a person, or stopped.
FAQ
Questions about website security
Can a static website be hacked?
It can be attacked, but it offers far less to attack. There is no login page to guess, no plugin to exploit and no database to break into, only finished pages served over HTTPS. What is left to protect is who can change the site, which is why every change has to come from a registered address, pass the checks and get your approval.
What stops someone pretending to be me?
Two checks. The email has to come from an address registered for your site, and your email domain has to vouch for it through DKIM, DMARC or SPF, the records that let a mail server tell a genuine email from a forgery. A forged sender is refused. An unknown sender gets no reply, and a person here is alerted.
Do I still need security updates or a security plugin?
No. The site has no WordPress core, theme or plugins, so there is nothing of that kind to patch and nowhere to install a security plugin. The pages are static HTML, served over HTTPS from Cloudflare Pages.
Could an old or forwarded email publish something?
Not something else. The Publish and Cancel buttons are signed links that name one exact change, work once and then expire. An old email cannot publish a newer change, and a button that has been used does nothing. Replies are safe too: quoted text from earlier emails is removed before any AI model reads your reply.
What if a published change turns out to be wrong?
Reply to the email about that change and ask for it to be undone. Every change is recorded in version history, and the undo is an exact reverse of it, so the page goes back to precisely what it was. The undo arrives as a preview, like any other change.
See where your website stands
We check your site for speed, Google visibility, AI visibility and content, then talk you through what we found. It is free, and there is nothing to sign.
R1 500 a month for the first 6 months, then R750 a month. No setup fee.