Hardening WordPress after migrating from an AI website builder
A security engineer's checklist for converted WordPress sites: updates, accounts, firewall, headers, backups and monitoring.
Convert2WP – convert your AI website to WordPressClick here
A different threat model
An AI builder hosts your site on a managed platform where the vendor patches the runtime, the database and the network. After a migration you take over that responsibility. WordPress itself is mature and well audited; most incidents I investigate are caused by outdated plugins, reused administrator passwords or abandoned test installations on the same server. Hardening therefore starts with process, not with exotic configuration.
Write down who has administrator access, which plugins are installed and who is responsible for updates. That one page of documentation prevents the majority of real-world compromises.
Accounts and authentication
Give every person their own account with the lowest role that fits their work: editors publish content, only one or two people need administrator rights. Enforce two-factor authentication for administrators, use a password manager and remove accounts the day someone leaves. Rename nothing for the sake of obscurity; a strong login with rate limiting is far more effective than hiding the login URL.
Disable the built-in file editor by adding DISALLOW_FILE_EDIT to wp-config.php. If an attacker ever obtains an administrator session, they cannot then inject PHP through the dashboard.
Server and HTTP layer
Run a supported PHP version, keep file permissions at 644 for files and 755 for directories, and make wp-config.php readable only by the web server user. Block PHP execution in the uploads directory. Add security headers at the server: Strict-Transport-Security, X-Content-Type-Options nosniff, a Referrer-Policy and a Content-Security-Policy that starts in report-only mode so you can see what would break before enforcing it.
A web application firewall, either at the host, at a CDN or as a plugin, filters common attack patterns such as SQL injection probes and credential stuffing before they reach PHP.
Updates, backups and recovery
Enable automatic minor core updates and update plugins weekly, first on a staging copy for larger sites. Keep daily backups of both files and database, stored off-site, with at least thirty days of retention. A backup is only real once you have restored it: test a full restore to staging every quarter and time how long it takes.
Uptime monitoring and a file integrity scanner complete the picture. They alert you within minutes rather than weeks, which turns a potential crisis into a routine fix.