How to protect your website
The basics that prevent most problems, without complexity.
Most breaches are not targeted. They are bots scanning millions of sites for open doors.
The basics
- An SSL certificate
- Keep the platform and plugins updated
- Strong passwords and two-factor authentication
- Automatic daily backups
- Keep plugins to a minimum
If you collect customer data
Never store card details — leave that to the gateway. For personal data, know exactly who can see it.
Backups are the last line of defence. Actually restore one once — an untested backup is not a backup.
If you are breached
Take the site offline, change every password, restore the last clean backup, then find the hole. In that order.
Turn the idea into a controlled launch
Start with the customer action the project must make easier: call, book, request a quote, buy or visit. That decision determines the page structure, content and tracking. A long feature list without a primary action usually produces an attractive project that nobody can measure.
Launch the smallest complete version, not a half-finished large version. Give one owner responsibility for content and approvals, test the full journey on a real phone, and record a baseline before launch. Improve from customer behaviour after launch rather than from internal opinions alone.
- Define one primary conversion and at most two supporting actions.
- Prepare final Arabic and English content before visual approval.
- Test forms, calls, maps, checkout and messages on real devices.
- Assign an owner and review performance every month.
A topic-specific field checklist
- Inventory accounts, code, dependencies, data, integrations and admin routes before choosing controls.
- Require multi-factor authentication for privileged users and least-privilege roles.
- Patch supported dependencies, rate-limit sensitive actions and log authentication and administrative changes.
- Test restoration and incident contacts; prevention without recovery is incomplete.
Details most proposals miss
Infrastructure quality appears when something changes or fails. Ownership, monitoring, recovery and controlled releases matter more than a long hosting feature table. The goal is not “never fail”; it is to reduce preventable failure and recover predictably.
- Business-owned domain, DNS, repository and production access.
- Separate development, preview and production release paths.
- Monitoring for uptime, application errors, performance and expiring services.
- Versioned backups with a tested restore objective.
- Patch and incident procedures with named responsibility.
The TechMate implementation layer
TechMate keeps the technical foundation understandable to the client. Releases have a visible history, important accounts are not trapped with one individual, and performance or security work is verified against a baseline.
- DNS and renewal inventory included in handover.
- Performance budgets for images, fonts and third-party scripts.
- Security checks aligned to actual data and privileged actions.
- Rollback route prepared before high-risk releases.
- Post-launch monitoring reviewed with business impact, not raw logs only.
Delivery phases that reduce risk
Improve infrastructure by reducing one known risk at a time and proving the control works. Configuration screenshots are not evidence of recovery, performance or security; tested outcomes are.
- Inventory assets, owners, dependencies and renewal dates.
- Capture a baseline for errors, speed and availability.
- Prioritise high-impact, likely failure modes.
- Release through preview with rollback prepared.
- Test monitoring and recovery after the change.
Questions that reveal implementation quality
- Who can recover each critical account?
- How old can restored data be?
- Which third party can block the service?
- What metric must improve after this change?
- What is the rollback trigger and procedure?
A realistic scenario
Example: an administrator account is compromised. MFA may block entry; if it does not, role limits, alerts and audit history should reduce damage and show what changed. Security is overlapping controls, not one plugin.
Sources directly related to this guide
Have a question this did not answer?
Send it over. We answer properly, whether or not you end up working with us.
