Last March, a physiotherapy clinic in Newcastle got in touch. Their original developer had stopped answering emails. The site still worked — patients could still book online — but the clinic manager had just logged into wp-admin for the first time in eighteen months. What she found was a mess: four contact form plugins, two SEO plugins, a custom post type called “Treatments” with zero entries, and a nav menu linking to three pages that returned 404s. She had no idea which plugins were safe to remove, whether the SEO setup was doing anything, or why someone had created a Treatments section that was never used. She needed to maintain a site she did not build, and the person who built it was gone.
Inheriting a WordPress site with no documentation is like being handed a novel with no chapter titles, no table of contents, and margin notes from three different people who disagreed with each other. The pages are there. The words are there. But the structure — the reasoning behind why things are where they are — is invisible. Before you touch a single setting, your job is to reconstruct the plot.
Why You Should Not Change Anything Yet
The temptation when you inherit a messy site is to start cleaning. Delete the duplicate plugins. Remove the empty custom post type. Consolidate the contact forms. Resist this. Every configuration choice on that site was made by someone who had a reason at the time. The reason might have been good or bad — but if you remove something without understanding why it exists, you risk breaking a function you did not know the site was performing.
That Newcastle clinic had four form plugins because the original developer started with Contact Form 7, switched to WPForms when the client wanted conditional logic, added Ninja Forms for a specific referral form that needed multi-page input, and then installed WP Mail SMTP to fix deliverability. Nobody removed the earlier plugins. Each one was a chapter in a story about what the client asked for and how the developer responded. The story matters because it tells you what the site is actually supposed to do — which is not always the same as what it currently does.
Professional operations teams in far more complex environments than a WordPress site follow this same principle: understand the current state and its history before intervening. Google’s Site Reliability Engineering book devotes entire chapters to troubleshooting methodology and postmortem culture — the practice of documenting what happened, why, and what was learned — because intervening in a system you do not understand reliably makes things worse. The book is written for engineers running global infrastructure, but the core lesson applies directly to a non-technical owner staring at a wp-admin dashboard full of plugins they did not install: effective troubleshooting requires understanding a system’s current state and history before making changes, not just listing what exists. Your first task is to write that history.
The Audit: Reconstructing the Site’s Backstory
Set aside about ninety minutes for this. You will not fix anything during this session. You will only read and record. Open a blank document — a Google Doc, a text file, a notebook, whatever you prefer — because you are going to build what I call a Site Decisions Log. This is the deliverable that turns a chaotic inheritance into something you and any future contractor can follow. I will walk you through the exact structure later. First, the audit itself.
Step 1: List Every Active Plugin and Guess Why It Exists
Go to Plugins → Installed Plugins in wp-admin. For every active plugin, write down its name, version number, and your best guess at what problem it was installed to solve. You are not assessing whether the plugin is good or bad yet. You are reconstructing intent.
For the Newcastle clinic, the list looked like this:
- Contact Form 7 (active, v5.8) — probably the first form plugin installed. No active forms using it. Likely superseded.
- WPForms (active, v1.8.6) — the main contact form on the Contact page. Two forms: “General Enquiry” and “Booking Request.”
- Ninja Forms (active, v3.7) — one form: “GP Referral.” Uses conditional fields. Embedded on a page called “Refer a Patient” linked in the footer, not the main menu.
- WP Mail SMTP (active, v3.5) — configured to send mail through the clinic’s Google Workspace account. This is why the forms actually reach the clinic inbox.
- Yoast SEO (active, v21.5) — the primary SEO plugin. Has configured meta titles and descriptions for the top five pages.
- All in One SEO (active, v4.5) — inactive on all pages. Probably installed before Yoast, never removed. No settings configured.
That list tells a story. The developer tried Contact Form 7, found it too limited, moved to WPForms, needed conditional logic for the referral form and added Ninja Forms, then hit an email deliverability problem and installed WP Mail SMTP. The SEO story is simpler: All in One SEO came first, Yoast replaced it, nobody cleaned up. You now know that WPForms, Ninja Forms, WP Mail SMTP, and Yoast are doing real work. Contact Form 7 and All in One SEO are candidates for removal — but not yet. You still have more to audit.
Step 2: Identify the Theme and Its Lineage
Go to Appearance → Themes. Note which theme is active and which themes are installed but inactive. Then go to Appearance → Theme File Editor (if available) and check whether there is a child theme — a separate theme that inherits the parent’s design but allows custom modifications without losing them during updates. If the active theme is a child theme, its name will usually include the parent theme’s name with “child” appended.
Write down the active theme name, its version, whether it is a child theme, and whether there is a custom CSS file or functions file with modifications. This tells you how much custom work the original developer did. A site running a stock parent theme with no child theme is easy to maintain — updates will not overwrite anything. A site with a child theme containing custom code in its functions file means someone added features programmatically, and you need to know that before updating the parent theme.
The Newcastle clinic was running a child theme of Astra with about forty lines of custom CSS in the child theme’s stylesheet. The CSS adjusted heading sizes and spacing for mobile screens. Low-risk custom work — it will survive a parent theme update without breaking. But I recorded it in the Site Decisions Log so that if the clinic ever switches themes, someone knows those CSS rules exist and can port them.
Step 3: Review User Accounts and Access Levels
Go to Users → All Users. For each user, note their username, role, and the date they last logged in (visible in the user list). This step is about security as much as reconstruction. The NIST Cybersecurity Framework — the US government’s structured approach to helping organizations understand and improve their cybersecurity risk management — treats inventorying what exists on a system, including who has access, as a prerequisite before making risk-informed decisions. The framework emphasizes producing documentation that non-technical stakeholders can understand and act on, which is exactly what your Site Decisions Log is doing for the WordPress site. Understanding what currently exists on a system — inventory, configurations, access — is a recognized prerequisite before making risk-informed maintenance decisions.
For each user account, ask three questions: Do I know who this person is? Do they still need access? Is their role appropriate? The Newcastle clinic had six user accounts: the clinic manager (Administrator), the original developer (Administrator), a second developer who worked on the site briefly in 2022 (Editor), a marketing consultant who left the clinic in 2023 (Author), and two accounts with display names but no real-world identity — “admin” and “testuser.” Both had Administrator rights.
That is a security problem, but it is also a narrative problem. Those accounts tell you that at least three different people had their hands in this site, and at least one of them left test accounts behind. Record all of it. You will deal with it later, but you need to know it now.
Step 4: Check Scheduled Content and Abandoned Drafts
Go to Posts → All Posts and click the “Drafts” filter. Then check “Scheduled” and “Pending Review.” Do the same for Pages → All Pages. Abandoned drafts and half-finished pages are like scattered chapter notes from a story someone started writing but never finished. They tell you what the site was supposed to become, which may be different from what it is now.
The Newcastle clinic had four draft pages: “Our Team,” “FAQ,” “WorkCover Claims,” and “Pilates Classes.” The WorkCover page was 80% complete — it had content, a booking form embed, and internal links — but it had been sitting as a draft for over a year. The Pilates page had a title and one paragraph. The other two were empty shells with titles only.
Reading through these drafts is reverse-engineering the site’s intended plot from incomplete notes. Before you decide whether to keep, rewrite, or delete each draft, you need to articulate what that page was supposed to accomplish. Sometimes the original intent is obvious — a WorkCover page helps patients understand insurance claims before their first appointment. Other times the purpose is murkier, and a structured story plot generator can help you work through the narrative arc each page was meant to serve: what problem does this page solve for the visitor, what action should they take after reading it, and where does it sit in the larger journey from finding the clinic to booking an appointment. Working through that structure for each draft makes it easier to spot which abandoned pages deserve completion and which were distractions the original developer never got around to removing.
That same discipline applies to narrative structure: before publishing, editors need a way to test events, claims, and consequences actually follow one another, which is where a story plot generator that fits the project can function as a planning aid rather than a substitute for domain evidence.
For the Newcastle clinic, the WorkCover page was clearly valuable and worth finishing. The Pilates page was aspirational — the clinic did not currently offer Pilates classes, so it was a placeholder for a service that might never launch. The “Our Team” and “FAQ” pages were standard clinic website features that the original developer scaffolded but never populated. I recorded all four in the Site Decisions Log with a recommendation for each: finish, hold, or delete.
Step 5: Check Redirect Rules and Broken Links
Redirects — instructions that send visitors from one URL to another — are often invisible in wp-admin because they are typically configured in a plugin, in the hosting control panel, or in a file called .htaccess that lives on the server. If a redirection plugin is installed (common ones include Redirection, Safe Redirect Manager, or Simple 301 Redirects), go to its settings page and export or screenshot the full list of redirect rules. If no redirect plugin is visible, check with your hosting provider’s support team and ask whether any redirects are configured at the server level.
Redirects matter because they preserve SEO value when pages move. If the original developer changed the site’s URL structure at any point, they may have set up redirects to send old URLs to new ones. If you later delete a page without checking for redirects pointing to it, visitors following old links will land on a 404 error page instead of the intended destination.
The Newcastle clinic had the Redirection plugin installed with twelve active rules. Most redirected old blog post URLs (previously formatted as /2019/06/post-name/) to new clean URLs (/post-name/). Two redirected deleted service pages to the closest current equivalent. I exported the full list and saved it as a CSV file in the Site Decisions Log folder.
Step 6: Read the Error Log
Go to Tools → Site Health and click the “Info” tab. Scroll down to the “Logs” section. If an error log is available, WordPress will display recent entries here. If your host provides a control panel (cPanel, Plesk, or a custom dashboard), you may also find error logs there under a section usually called “Logs” or “Metrics.”
The error log is the site’s confession. It records PHP warnings, notices, and fatal errors — messages generated when something in WordPress, a theme, or a plugin encounters a problem. Most warnings are harmless (a plugin using a deprecated WordPress function that still works but will eventually stop). Fatal errors indicate something that broke at a specific time. Reading the error log tells you what is already wrong before you start making changes.
The Newcastle clinic’s error log showed recurring warnings from Contact Form 7 about a missing configuration file and a fatal error from three months ago when All in One SEO conflicted with a WordPress core update. The error lasted two days before an automatic plugin update resolved it. This confirmed that both plugins were not just redundant but actively causing problems — and it gave me a timeline for when the conflict occurred.
Building the Site Decisions Log
Now you have enough information to write the site’s backstory. The Site Decisions Log is a living document — you will update it every time you make a significant change going forward. Here is the structure I use, which you can copy into a Google Doc or text file:
Section 1: Site Overview
Site URL, hosting provider, WordPress version, active theme name and version, date of this audit, and your name as the person who performed it.
Section 2: Plugin Inventory
For each plugin: name, version, active or inactive, what it does, what problem it was installed to solve (your reconstruction), and whether it is currently needed. Flag duplicates and candidates for removal.
Section 3: Theme Notes
Active theme, parent theme (if applicable), whether a child theme exists, custom code locations (CSS file, functions file), and any modifications that need to survive a theme update or switch.
Section 4: User Accounts
Each user’s username, role, last login date, real-world identity (if known), and recommendation (keep, change role, remove). Flag unknown accounts immediately.
Section 5: Content Audit
Published pages and posts with their purpose, draft pages with recommendations (finish, hold, delete), orphaned content (pages not linked from any menu), and any custom post types with their usage status.
Section 6: Redirects
Full list of redirect rules, where they are configured (plugin or server), and why each was created (if determinable).
Section 7: Error Log Summary
Date range of available logs, recurring warnings and their source, any fatal errors and when they occurred, and what was done to resolve them (if anything).
Section 8: Decisions Log
A running list of changes you make after the audit, with the date, what changed, why, and the result. This section starts empty and grows over time.
What to Do With What You Found
Once the Site Decisions Log is complete, you have the site’s backstory. You know what it was supposed to do, what decisions were made along the way, and which of those decisions still make sense. Now — and only now — you can start making changes.
For the Newcastle clinic, the first changes were straightforward. I removed the two unknown Administrator accounts, changed the original developer’s account to Subscriber (so if they ever logged in again, they could not change anything), and deleted the marketing consultant’s account. I deactivated and deleted Contact Form 7 and All in One SEO, then watched the site for forty-eight hours to confirm nothing broke. I finished the WorkCover page and published it, deleted the empty “Our Team” and “FAQ” drafts (the clinic decided they were not priorities), and left the Pilates draft in place with a note in the Site Decisions Log that it was aspirational, not abandoned.
Each of those actions got an entry in Section 8 of the log. The clinic manager now has a document that explains why those plugins were removed, what was kept, and what the site’s content is supposed to achieve. If she ever hires a new developer, that person starts with context instead of mystery.
Prevention: Keep the Log Alive
The Site Decisions Log only works if you maintain it. Every time you install a plugin, add a user, change a theme setting, create a redirect, or publish a new page, add an entry to Section 8. It takes thirty seconds. It does not need to be eloquent — “Installed Rank Math SEO plugin to replace Yoast, 15 March 2026, because Yoast’s free version no longer supports schema output for LocalBusiness” is enough. The point is that the next person to inherit this site — which might be you in six months when you have forgotten what you did — does not have to reconstruct the plot from scratch.
The Newcastle clinic manager updates her log about once a month. She told me recently that the most useful entry is the one explaining why the site uses two different form plugins. Without that note, she said, she would have assumed one was a mistake and deleted the wrong one. That is exactly what the Site Decisions Log is for: turning a confusing inheritance into a story that makes sense, one decision at a time.