Quick Answer
A WordPress backup restore checklist should pair the database export with the matching wp-content files, record when the backup was taken, keep the restore path separate from normal update work, and verify the site after recovery with login, homepage, media, plugin, permalink, and Site Health checks. For a small publisher, the best fit is a simple backup set and recovery note that can be used before updates, plugin changes, or incident response.
Minimum Restore-Ready Checklist
| Check | Operator action | Evidence to keep |
|---|---|---|
| Backup set | Store the database export and file backup from the same window | Timestamped backup folder |
| Database export | Confirm the export format and database name before archiving | .sql, .gz, or host export note |
| WordPress files | Include wp-content, uploads, themes, plugins, and wp-config.php | File archive manifest |
| Update timing | Take a fresh backup before WordPress core, theme, or plugin changes | Pre-update checklist |
| Rollback owner | Name who can restore files and import the database | Recovery owner note |
| Restore order | Restore files first, then import the matching database | Restore runbook |
| Post-restore checks | Review login, homepage, media, permalinks, plugins, and Site Health | Recovery checklist |
| Refresh date | Recheck the process after host, plugin, or server changes | Update log |
Who This Checklist Is For
This checklist is for WordPress publishers, AdSense-focused blog operators, and small editorial teams that need a practical recovery plan without turning the article into professional disaster-recovery consulting. It is not a hosting benchmark, legal compliance guide, or guarantee that any one backup plugin will recover every site.
The operating problem is that WordPress content is split across more than one place. Official WordPress backup documentation separates the database from the files. The database holds posts, pages, comments, settings, and other stored site data. Files include WordPress core, plugins, themes, uploads, scripts, wp-config.php, and related assets. A file-only download is not a complete recovery plan, and a database-only export will not restore uploaded images, themes, or plugin code.
For Yolkmeet-style operator-tech publishing, backup work should be treated like editorial quality control. The backup is useful only if the next operator can answer three questions quickly: what is included, when was it created, and what exact restore path should be followed if an update or site incident goes wrong.
Step 1: Define One Backup Set
A restore-ready backup set has two matching parts: the database export and the WordPress files. The official WordPress backup guidance recommends treating files and database as one set, because restoring a typical WordPress site requires both. The database export can sit inside the same archive folder as the file backup, but it still has to be imported into MySQL or MariaDB during restoration.
Use this structure:
| Backup folder item | Why it matters |
|---|---|
database.sql or compressed database export | Restores posts, pages, comments, settings, and stored plugin data |
wp-content/ archive | Restores uploads, themes, plugins, and user-generated site files |
wp-config.php copy | Confirms database connection details and site constants |
backup-manifest.txt | Lists source host, timestamp, WordPress version, PHP version, and database name |
restore-notes.md | Records the recovery owner, target host, and verification checklist |
This does not mean every operator should manually manage every file forever. It means the backup process should produce a package that can be understood without guessing. If a host backup, backup plugin, or shell script creates the set, the operator still needs the manifest and restore notes.
Step 2: Back Up Before Update Work
WordPress update documentation recommends backing up the website before updating so the site can be restored if something goes wrong. The same principle applies before theme changes, plugin bulk updates, permalink changes, migration work, or large media cleanup. Plugin and theme auto-update documentation also points operators toward regular automatic backups before relying on auto-updates.
Use this decision table before changes:
| Change | Backup requirement | Better choice |
|---|---|---|
| Minor content edit | Normal revision history may be enough | Save draft and keep source notes |
| Plugin update | Fresh database and file backup | Update one group, then check the site |
| Theme change | Fresh backup plus screenshot of current layout | Keep rollback path visible |
| WordPress core update | Fresh full-site backup | Record WordPress version before and after |
| Permalink or redirect change | Backup plus redirect notes | Avoid URL churn without a restore path |
| Media cleanup | Backup uploads and database | Confirm images still load afterward |
The practical rule is simple: if the change could break the public site, create or confirm a backup set first. If the change only updates one article draft, keep editorial revision notes instead.
Step 3: Keep Database And Files Together
Official WordPress file-backup guidance notes that the database usually lives outside the WordPress directory, so downloading files from the server does not normally back up the database. It also calls out wp-content and wp-config.php as especially important file areas. That split is where many small-site backup plans become fragile.
Use this backup pairing checklist:
- [ ] Record the backup timestamp in UTC or the site's operating timezone.
- [ ] Export the database and label the file with the site name and date.
- [ ] Archive
wp-content, including uploads, plugins, and themes. - [ ] Keep a copy of
wp-config.phpin a secure operator-only location. - [ ] Confirm the database export and file archive belong to the same site.
- [ ] Store the pair away from the live web root when possible.
- [ ] Keep old backups long enough to survive a delayed discovery of a bad update.
Do not publish credentials, salts, database passwords, or private backup paths in an article, screenshot, or public repository. A public checklist can describe the evidence to keep; the actual recovery package belongs in a controlled storage location.
Step 4: Write The Restore Order Before It Is Needed
WordPress backup documentation describes the typical restore order as restoring files first, then importing the database. Database documentation describes restoration as importing the backup into MySQL or MariaDB. For a small publisher, the important operator move is not memorizing every hosting panel. It is writing down the path that applies to the current host before a failure happens.
Use this restore-order note:
| Restore phase | Operator question | Evidence to keep |
|---|---|---|
| Freeze changes | Is anyone still editing the site? | Incident note |
| Restore files | Which archive restores wp-content and config files? | File restore log |
| Import database | Which database receives the matching export? | Import log or host ticket |
| Confirm config | Did database credentials or host names change? | wp-config.php review note |
| Check public pages | Do homepage, posts, media, and category pages load? | URL checklist |
| Check admin | Can an operator log in and see expected plugins/themes? | Admin checklist |
| Check Site Health | Are critical issues, loopback, upload, and update checks visible? | Site Health note |
This is a runbook, not a recovery promise. The article should not claim a specific backup has been restored unless the operator has a private evidence file outside the public content queue. The public page should teach the structure and decision points.
Step 5: Verify The Site After Recovery
Restoring a database and files is not enough if the public site is still broken. WordPress Site Health documentation exposes useful checks for WordPress version, theme, plugins, uploads, server details, database details, filesystem permissions, update communication, and whether the site is discouraging search engines. Those checks make a good post-restore review surface.
Use this post-restore checklist:
- [ ] Homepage returns the expected public page.
- [ ] A recently published post loads with images.
- [ ] The WordPress admin login works for the operator account.
- [ ] Active theme and active plugins match the expected state.
- [ ] Media uploads and existing images work.
- [ ] Permalinks and redirects still send readers to the right URLs.
- [ ] Site Health shows no unexpected critical issue from the restore.
- [ ] Search visibility settings did not change during recovery.
- [ ] The incident note records what was restored and why.
This fits AdSense-oriented operations because recovery quality affects crawlability, reader trust, and the ability to keep publishing stable articles. It does not add affiliate recommendations, urgency language, or manufactured traffic tactics.
What Should A Solo Publisher Back Up First?
Start with the pieces that cannot be rebuilt easily. WordPress core files can usually be replaced from a clean download, but uploads, themes, plugins, custom files, and the database represent the site's actual content and configuration. The best fit for a solo publisher is a repeatable backup set around the live site, not a complex enterprise recovery plan.
Use this priority order:
1. Database export for posts, pages, comments, settings, and stored plugin data. 2. Uploads and media files under wp-content. 3. Active theme and any child-theme customizations. 4. Active plugins and plugin configuration evidence. 5. wp-config.php and server-specific notes stored securely. 6. Redirect, permalink, sitemap, and Site Health review notes. 7. Older backup retention rules for delayed update failures.
If a site has only one current backup and no restore note, the next improvement should be documentation, not another tool comparison. A backup is an operator asset only when someone can use it under pressure.
Common Questions
Does backing up WordPress files also back up the database?
Usually no. WordPress files live in the site directory, while the database is stored in a separate database system. A complete recovery plan needs both a database export and the matching file backup.
When should a blog operator create a new backup?
Create or confirm a backup before WordPress core updates, theme changes, plugin bulk updates, permalink changes, migration work, or media cleanup. Routine article edits can usually rely on editorial revision notes instead.
Should small publishers rely only on host backups?
Host backups can be useful, but the operator should still know what is included, how long backups are retained, who can restore them, and whether the database and files are restored together. The decision criteria are recoverability and clarity, not the label on the backup tool.
What is the minimum post-restore evidence?
Keep a short note showing the restore timestamp, restored backup set, public URL checks, admin login check, media check, plugin/theme review, and Site Health review. That evidence helps the next operator understand what changed.
Source Notes
This article was checked against official docs on 2026-06-06. WordPress backup documentation informed the database-plus-files backup set, backup order, and restore order sections. WordPress database backup documentation informed the database export and import guidance. WordPress file backup documentation informed the wp-content, uploads, theme, plugin, and wp-config.php checks. WordPress update and plugin/theme auto-update documentation informed the pre-update backup trigger. WordPress Site Health documentation informed the post-restore verification list.
Update Log
Review this checklist every 90 days. Recheck official WordPress backup, database, file, update, auto-update, and Site Health documentation before changing the checklist. Refresh earlier if the hosting stack, backup tool, WordPress version, active theme, or recovery owner changes.