Website troubleshooting becomes risky when every person tries a different fix and none of the changes are recorded. A maintenance change log creates a shared timeline: what changed, who changed it, what was expected, what failed, and how the site was verified afterward.
Capture the incident before editing
Record the first observed time with time zone, affected URL, expected result, actual result, HTTP status or visible error, user role, browser and device, and whether the issue appears in a private window or another network. Save relevant screenshots and log references without copying passwords, customer data, or secret tokens. Check whether the issue affects one page, one function, or the whole site.
Create an incident entry separate from routine maintenance. Link it to recent changes in code, theme, plugins, content, DNS, certificates, hosting, caching, forms, analytics, or third-party services. Do not deploy another change until the original state and evidence are preserved.
Maintain a precise change log
Every maintenance entry should include timestamp, operator, affected component, old version or value, new version or value, reason, approval, backup or revision reference, expected result, rollback step, and verification result. For automatic updates, identify the system or service that performed the change. For content changes, record the page and field rather than storing unnecessary copies of personal data.
WordPress's Site Health screen reports critical issues and recommended improvements and provides technical information about themes, plugins, server configuration, database, and filesystem permissions. Its Info tab can copy the site information for diagnosis. Source: https://wordpress.org/documentation/article/site-health-screen/
Capture that baseline before a significant change and again after a problem, then compare only the relevant differences. Site Health is diagnostic evidence, not a complete change history.
Use logs safely
WordPress documents WP_DEBUG and WP_DEBUG_LOG for gathering errors, notices, and warnings, but it says debugging tools are intended for local or staging copies rather than live sites. It also warns that errors can expose sensitive information and advises verifying a staging environment or appropriate backup before modifications. Source: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
If debugging must be enabled under an approved procedure, record who enabled it, the exact time, where the log is stored, who can access it, and when it is disabled. Do not display errors to visitors. Minimize retention of logs that contain paths, queries, user information, or other sensitive details.
Correlate the failure with the timeline
Compare the first failure with recent entries. Start with a change affecting the same page or dependency. Check external service status before assuming the site code is at fault. Reproduce the problem on staging or a draft environment when possible. Test one hypothesis at a time: cache, plugin, theme, configuration, content, database, network, or third-party service.
WordPress's maintenance guidance recommends scheduled backups, checking logs for 404 errors, checking internal and external links, and validating after changes to code or styles. Source: https://wordpress.org/documentation/article/wordpress-site-maintenance/
Use those checks as part of the verification record. A fix for one visible page is incomplete if it breaks navigation, forms, checkout, accessibility, or another critical path.
Roll back the smallest verified cause
If the evidence points to one change, reverse that change through a supported method and record the exact revision or setting restored. Avoid restoring the entire site when a smaller, verified rollback is available. If the cause is uncertain, preserve the current database and files before any broad restore and use the site's recovery plan.
After correction, verify the affected URL and the critical user journeys. Record response status, page rendering, navigation, forms, authentication, transactions where applicable, and log behavior. Close the incident with the confirmed cause, correction, evidence, affected window, and follow-up prevention.
A good website change log makes maintenance observable. It does not guarantee that changes never fail; it makes failures bounded, explainable, and safer to reverse.
Sources
- Site Health screen — WordPress.org
- Debugging in WordPress — WordPress.org
- WordPress site maintenance — WordPress.org