Kinsta Backup & Maintenance Workflow
Best practices for safely performing maintenance on Kinsta-hosted WordPress sites. The core principle: always confirm backups exist before touching anything. Kinsta's automatic backup system makes this straightforward, but the steps below should be followed every time.
Why This Matters
When working on a client site we don't host ourselves, we have no control over the server environment and limited visibility into what's been changed. A mistake without a restorable backup can be expensive and relationship-damaging. This workflow was formalized after scoping maintenance work on the [1] site in February 2026.
Pre-Work Checklist
1. Verify Backup Availability in Kinsta Dashboard
Before making any changes, log into the Kinsta dashboard and confirm automatic backups are enabled and recent.
Navigation path:
Kinsta Dashboard → Sites → [Client Site] → Live → Backups
If backups are present and current, it is safe to proceed. If not, do not begin work until a manual backup is created or the client confirms their backup situation.
Note: Kinsta's automatic backups are not always visible from within the WordPress admin panel itself (under Tools or elsewhere). You must check the Kinsta dashboard directly.
2. Confirm SSH / SFTP Access
Backend work (database cleanup, plugin fixes, SEO audits) requires more than WordPress admin access. Confirm you have one of the following:
- SSH access — preferred for efficient backend work (WP-CLI, direct file access)
- SFTP access — fallback for file transfers
Where to find credentials:
Kinsta Dashboard → Sites → [Client Site] → User Management or Info tab
If SSH credentials are not already set up, you may need to create a new server user or request access from the client. Do not assume WordPress admin login is sufficient for backend operations.
3. Note the Hosting Environment Differences
Kinsta sites may use different plugins and configurations than WP Engine-hosted sites. Before running any automated tools or scripts, audit the active plugins:
- Caching plugins (Kinsta uses its own cache layer; third-party cache plugins may conflict)
- Security plugins
- Page builders (e.g., Divi requires extra care and significantly increases task time)
Performing Maintenance
Safe Sequence
- Log backup timestamp — note the most recent automatic backup before starting
- Create a manual backup if the most recent automatic backup is more than 24 hours old
- Work on staging first if a staging environment exists (Kinsta provides one per site)
- Push to live only after verifying changes on staging
Common Maintenance Tasks
| Task | Access Required | Notes |
|---|---|---|
| SEO metadata fixes | WordPress admin | Can be done via plugin or bulk editor |
| Database cleanup (orphaned data, transients, autoload) | SSH / WP-CLI | Cannot be done reliably from WP admin alone |
| Broken link repair | WordPress admin | Use Ahrefs or similar to identify; fix in editor |
| Plugin updates | WordPress admin | Test on staging first |
| Image optimization | WordPress admin or SSH | Bulk tools require SSH for large sites |
| Cache clearing | Kinsta dashboard or admin bar | Kinsta cache must be purged from dashboard |
What You Cannot Do Without Backend Access
If you only have WordPress admin login (no SSH, no hosting dashboard access), the following are not possible:
- PHP-level fixes and custom plugin deployment
- Direct database access (phpMyAdmin equivalent)
- DNS record management
- Automated monthly audit scripts
This is the same limitation encountered with [2] after their unauthorized DNS migration — front-end login exists, but backend tooling is completely blocked.
Authentication & Credential Management
Kinsta accounts typically require two-factor authentication (2FA). Ensure the following are stored in LastPass before starting a session:
- Kinsta dashboard login (email + password)
- TOTP authenticator entry for Kinsta 2FA
- WordPress admin credentials for the specific site
- SFTP/SSH credentials (if configured)
If a Kinsta account requires email verification as an additional step, coordinate with whoever owns the team email inbox before scheduling maintenance work.
After Maintenance
- Verify the site loads correctly on both desktop and mobile
- Check Ahrefs (or equivalent) error count to confirm issues were resolved
- Clear Kinsta's server cache from the dashboard
- Log what was done and update the client's site documentation
- Note any issues that require SSH access that wasn't available, so they can be scoped separately
Related
- [1] — first site where this workflow was formalized; 169 Ahrefs errors identified, Divi builder in use
- [2] — counterexample: DNS migration removed all backend access, illustrating what's lost without proper infrastructure control
- [3] — how DNS configuration affects backend tool access
- [4] — the automated audit workflow that requires backend access to run