WordPress maintenance serviceKey points
Four points for a sound decision
- Do not start more bulk updates or blindly clear caches as the first step.
- Document the symptoms, time, affected pages and latest change.
- Before a rollback, establish which orders, form submissions or content have been created since the backup.
- After a fix or restore, recheck core functions, forms and background processes.
- 01Freeze the state
- 02Assess the impact
- 03Choose a fix or rollback
- 04Verify operations
Our own process illustration · not a generic vendor guarantee · the actual process depends on the website and service profile.
01
The first ten minutes: limit the damage
Record the time, visible message and action performed immediately beforehand. Check the homepage, an important subpage, login and, if business-critical, checkout or a form. Avoid repeatedly opening the website through different tools; relevant states and timing relationships can quickly be lost.
If only the frontend is affected, a single plugin, theme or cache layer may be responsible. An HTTP-500 error requires checking PHP and web server logs. A white screen does not automatically justify a full restore: a small, clearly reversible fix may cause less data loss.
- HTTP status and affected URLs
- Admin access and maintenance mode
- PHP/web server errors at the relevant time
- latest plugin, theme or core change
- new business data since the recovery point
02
Fix or rollback?
A rollback makes sense when the change can be clearly isolated, a recent verified recovery point exists and no irreplaceable transactions have occurred since the backup. For shops, bookings or forms, a full database rollback can overwrite new customer data. Files, the database and individual tables must then be considered separately.
A targeted fix is often better when only one component is affected and the cause has been reliably identified. Even then: back up first, make the change, then repeat the same core checks as before the intervention. A homepage that loads successfully is not sufficient proof of completion.
03
What is checked after recovery
Technical checks cover status codes, key public pages, login, forms, scheduled tasks and, depending on the website, checkout or other business processes. Caches must then be refreshed selectively. The cause and decision must be recorded in the maintenance evidence so the same error is not repeated during the next update.
Kayba links changes to a recent off-site recovery point and documents the result or rollback decision. This reduces risk but does not guarantee error-free third-party software. During an acute incident, a qualified person remains responsible for the decision.
Review basis
Primary sources and our operational status
The technical principles were checked against the following vendor documentation on 10.09.2026. Plan values and Kayba processes come from our versioned service catalogue and operations system.
Sources support general product and operational principles. They are not endorsements or certification of Kayba by the named vendors.