Dependency Maps for Small Sites: Finding the Hidden Single Points of Failure
Most small sites go down for reasons that have little to do with the server humming in a data center. A payment widget stops loading, a font CDN times out, a plugin update breaks a form, or a DNS record was edited by someone who forgot why it existed. When the site feels broken, the team often starts guessing. A dependency map replaces guessing with a written inventory of everything the site needs in order to work. This article walks through how to build one, what questions to ask about each dependency, and how to use the map during an outage. The goal is not to eliminate every risk. It is to know, before an incident, which pieces are load-bearing and who can act on each of them.
Start With What a Visitor Actually Needs
Begin with a single page that matters most to your business, such as a homepage, a product page, or a contact form. List every resource the browser must fetch to render it and to complete the main action. Open the browser developer tools, switch to the network tab, and reload the page with the cache cleared. Each request is a dependency. You will likely find images on your own origin, scripts from analytics providers, fonts from a content delivery network, embedded video, a chat widget, and API calls to a form handler.
Repeat the exercise for the checkout or submission flow, since that is where dependencies tend to multiply. Note which requests are required for the page to function and which are cosmetic. A failed analytics beacon rarely matters to a visitor. A failed call to an address validation service may block a purchase entirely. Mark each dependency as either critical to the core action or non-critical. This single distinction changes how you respond when something fails.
Map the Layers Behind the Page
Visible requests are only the top layer. Underneath, a site relies on DNS records, the registrar where the domain is held, the certificate that secures the connection, the web server configuration, the application runtime, the database, scheduled jobs, outbound email delivery, and backups. Write each of these in a table with columns for the service, the provider or tool, the person or role responsible for it, where its configuration lives, and how you would know it had failed.
The responsibility column deserves more attention than it usually gets. Many small teams discover during an incident that the only person who can change a DNS record left the company months ago, or that the registrar login is tied to an email address nobody monitors. Record who holds access, and confirm that at least two people can reach each critical account. Also record where the documentation for each layer lives, so that an on-call person does not have to reconstruct the setup from memory.
Ask the Right Questions of Each Dependency
For every item on the map, ask a consistent set of questions. What happens to visitors if this stops responding for thirty minutes? What happens if it returns an error rather than timing out? Does the site degrade gracefully, showing a message or hiding a widget, or does one failed request block the whole page? Is there a documented way to disable or bypass this dependency quickly, such as a feature flag, a configuration toggle, or a fallback endpoint?
Also ask how you would find out. Some failures announce themselves loudly, while others, like a third-party script that quietly stops reporting conversions, can persist for weeks. Decide which dependencies warrant an active check and which are reviewed on a schedule. Finally, ask about change control. Who can modify this dependency, and does a change to it get recorded anywhere? Silent edits are a leading cause of confusing outages.
Use the Map During an Incident
When something breaks, start from the map rather than from intuition. Work through the layers in order: confirm DNS resolves to the expected address, confirm the certificate is valid and not expired, confirm the origin responds, then check the application and the critical third-party calls. Compare what you observe with what the map says should happen. If a critical dependency is failing, your options are to wait for the provider, switch to a documented fallback, or disable the feature that depends on it. Writing these options into the map beforehand turns a stressful decision into a lookup.
After the incident, update the map. If you discovered a dependency that was not listed, add it. If a fallback did not work as described, correct the note. A dependency map is only useful while it reflects the real system, and it drifts quickly when plugins are added or vendors change.
A Short Checklist for Your First Map
Pick your most important page and capture every request it makes. Label each dependency as critical or non-critical. Extend the list down to DNS, registrar, certificate, server, application, database, email, and backups, naming an owner for each. Confirm that two people can access every critical account. Record where configuration and documentation live. For each critical dependency, write one sentence describing the degraded behavior and one describing a fallback or disable step. Schedule a review date, and revisit the map after every plugin change, provider switch, or incident.
Hosting choices also shape this map. A shared plan, a managed WordPress environment, and a VPS each divide responsibilities differently between provider and team, so the same table will have different entries filled in by someone else. Whatever your setup, the exercise is the same: know what your site needs, who controls it, and what you will do when it stops. A map drawn in an afternoon will shorten your next outage more than any single tool.