A homepage is usually the visible edge of several systems: the domain registrar, DNS provider, web host, content management system, theme, database, forms, analytics, and third-party integrations. A screenshot captures appearance but cannot restore those dependencies. Begin with a one-page ownership map listing each service, the business-controlled account, renewal date, authorized recovery contact, and where credentials are stored. Do not place passwords in the map. Record the current domain, DNS entries, hosting plan, site platform, active theme, form destination, analytics identifier, and any external scripts.
Back up the complete site
For a WordPress site, the official backup guidance says a full recovery generally needs both the database and the site files, and those parts should be treated as one backup set: https://developer.wordpress.org/advanced-administration/security/backup/. Create them at the same point in time and label them with one shared date. Keep multiple generations in separate locations rather than leaving the only backup on the web server. WordPress also recommends maintaining several backups in different places and periodically supplementing automated backups with a manual one.
Preserve the change baseline
Before editing the homepage, save the current theme or template files, export the database, capture the page text and images, and record the active configuration. WordPress server guidance recommends testing server changes in staging where possible, keeping the original configuration, and making a current backup before changing files or the database: https://developer.wordpress.org/advanced-administration/server/. If the host offers snapshots, document whether a snapshot includes both files and the database and how long it is retained.
Restore in a safe place first
Build a temporary or staging copy and restore the latest set there. Check the homepage at mobile and desktop widths, then test navigation, forms, contact destinations, privacy links, image loading, and the secure connection. WordPress warns that online file edits take effect immediately and describes editing copies offline, testing them, then uploading; it also notes that a broken file can be replaced from backup: https://developer.wordpress.org/advanced-administration/wordpress/edit-files/. A staged restore confirms more than the existence of an archive: it shows that the archive, instructions, and access rights work together.
Keep an incident checklist
Write the shortest safe sequence for recovery: stop unnecessary edits, capture evidence, confirm the most recent known-good backup, restore in staging, compare the result, obtain approval for a live rollback, and monitor forms and traffic afterward. Do not change DNS or overwrite production simply because the homepage looks wrong. Regular full snapshots and integrity controls such as checksums can strengthen backup handling, according to WordPress hardening guidance: https://developer.wordpress.org/advanced-administration/security/hardening/. Review the ownership map quarterly and perform a staging restore after major design or platform changes.
Sources
- WordPress Backups — WordPress Developer Resources
- Server Environment — WordPress Developer Resources, July 1, 2026
- Editing Files — WordPress Developer Resources
- Hardening WordPress — WordPress Developer Resources