In brief
A green message does not prove an update succeeded. Test your own business features and plan complete recovery in advance.
Kezdd azzal, mit nem szabad elrontani
List critical tasks: enquiries, sign-in, purchases, payments, billing and email. Five short tests may suffice for a simple business website; an online store’s order journey involves more parties and integrations. Give every test an expected result and an owner.
Record the current WordPress, PHP, theme and important plugin versions. Alongside the update list, read release notes and compatibility information. If a custom change is undocumented, first identify where it is and what it does. Do not investigate uncertain behavior on the live website.
Keep backups complete and recoverable
WordPress needs both its files and database. Posts, settings and orders may be stored in the database, while uploads, themes and plugins are files. Downloading one directory does not necessarily back up the whole site. Check that you also have the access needed for recovery.
Do not just create a backup: restore it in a separate environment. Open an older image, sign in, and check a product and an important setting. Record the backup time. If orders can arrive meanwhile, restoring the database may lose them; agree on the maintenance window and handling of new data in advance.
Keep the test environment separate from live business operations
Block indexing on the test copy, restrict access and do not send real customer emails. Use test mode for payments and handle billing and inventory separately. A production database copy may contain sensitive customer data, so control access and retention too.
Capture screenshots or short notes on critical features before updating. Check more than desktop: open menus and forms on a phone too. Different caching or PHP settings in staging may hide production issues, so document the differences.
Update and verify in small steps
The correct update order depends on dependencies; no single plugin checklist fits every website. Test critical components separately and record which change preceded a problem. Use the supported update procedure and make a separate copy before modifying files manually.
If an error appears, do not continue by trial and error. Record the exact action, time and message. Review the relevant log and share only the necessary, non-sensitive excerpt with the developer. Passwords, keys and personal data do not belong in a general support ticket.
Continue checking after launch
Schedule production updates for a quieter period. Then repeat critical tests, review errors and verify that emails actually arrive. Define rollback criteria in advance; for example, do not wait until the next day if payments fail.
The completed log should include versions, backup locations, test results and unresolved issues. Regular maintenance should make this workflow repeatable. Automatic updates are convenient, but do not replace monitoring or testing business functionality.
Example: payments break in an online store
Imagine a test where product pages and the cart work, but the order fails to change status after the payment provider’s callback. Investigate the entire payment flow. Opening checkout alone does not prove that background notifications, inventory handling and email work too.
Create a specific test order in the appropriate test mode. Record its identifier and expected state changes. Do not initiate a real financial transaction just to verify an update. Keep sandbox credentials separate from live settings.
What should a maintenance report contain?
Rather than a short list, the report should provide verifiable results: which components changed to which versions, when backups were made, which actions were tested and what remains outstanding. Agree on the scope of monitoring, updates and troubleshooting in advance. Do not assume a maintenance contract includes custom development.
If a plugin is no longer supported, request a replacement plan. Replacing it may require migrating data and reviewing old settings and related theme components. Decide based on business functionality and maintainability, not simply the age of its latest release.
- Backup: files and database, with a documented recovery procedure.
- Functionality checks: sign-in, forms, purchases and notifications.
- Handover: a log of versions, verified actions and outstanding tasks.
