I have become more interested in website documentation because of the moments when it is missing.
Nobody asks for documentation when everything is fresh. The developer remembers how the build works, the client remembers the handover and the project manager still has the decisions in their head. Six months later, the situation is different. Someone new needs to edit a page, a plugin behaves strangely, a campaign needs a new template and nobody is completely sure why the site was built in a certain way.
That is when documentation stops feeling like admin and starts feeling like infrastructure.
Documentation Should Answer Real Questions
I do not think website documentation needs to be long to be useful. In fact, long documentation often becomes a place where important details get buried. The better question is what someone will need to know when the original project team is not available.
Where are the main templates? Which blocks should editors use for common pages? How are forms routed? Which plugins are essential? What should be tested after updates? How does deployment work? Those are the questions that save time later.
The documentation should be written for the person inheriting the website, not for the person who built it. That usually means less clever explanation and more practical direction.
Writing Down Decisions, Not Just Instructions
Instructions are useful, but decisions are often more valuable. If a template was built in a particular way because the client needed control over one section, that context should be recorded. If a plugin was chosen because replacing it would have taken too long during the project, that should be visible too.
Without that context, future changes become riskier. A developer may remove something that looks unnecessary without knowing what depended on it. An editor may work around a pattern because they do not understand why it exists. The website starts losing the reasoning behind its structure.
I like documentation that explains why the site behaves the way it does. Not every detail needs a story, but the important decisions should not live only in memory.
Keeping It Close To The Work
The best documentation is close to the work it describes. Some of it belongs in the repository, especially setup notes, build commands and deployment details. Some belongs in WordPress, especially editor guidance and pattern explanations. Some belongs in a shared project space where non-developers can find it.
The format matters less than whether people can actually find and maintain it. A beautiful document that nobody updates becomes stale quickly. A simple page that gets revised after each meaningful change is far more useful.
I also think documentation should be reviewed during maintenance. If a process changes, the documentation should change with it. Otherwise it becomes a record of how the website used to work, which can be worse than having nothing because it creates false confidence.
Retrospective Thoughts
Documentation is not there to make the project look more professional. It is there to reduce dependency on memory. That matters because websites often outlive the teams that built them.
The quiet value of documentation appears when someone needs to make a decision under pressure. A clear note, a recorded reason or a simple update route can prevent hours of guessing. That is why I now treat documentation as part of the build rather than something to tidy up if there is time at the end.