Inspect the system before trusting the symptom

When something goes wrong with a website, the first report almost always describes a symptom. "Leads dropped." "The site is slow." "Our emails aren't getting through." Those reports are useful. They tell you where someone felt the pain. They rarely tell you what broke.

The mistake I see most often is treating the symptom as the diagnosis. Leads dropped, so it must be SEO. The site is slow, so we need a new host. Emails aren't arriving, so the email provider must be bad. Each of those conclusions leads straight to spending money, and each can be completely wrong.

My rule is simple: inspect the system before trusting the symptom. It's the practical side of an idea I wrote about in every web problem eventually becomes a systems problem. If the website, tracking, server, forms and CRM are one machine, then a symptom in one place can have its cause anywhere along the line.

Symptom versus root cause

A symptom is an observation. A root cause is the specific thing that, if fixed, makes the symptom go away and stay away.

The gap between them matters because fixes applied at the symptom level tend to be expensive and temporary. If leads dropped because a form stopped submitting on some mobile browsers, then more ad budget will buy more visitors who also can't submit. If a site is slow because one third-party script blocks rendering, then a bigger server changes very little.

Good troubleshooting is mostly about resisting the obvious explanation long enough to check the less obvious ones. And most of the less obvious ones are cheap to check.

Patterns that come up again and again

These aren't rules. They're patterns I've seen often enough that I check them early, before accepting the explanation that first comes to mind.

"Leads dropped." The instinct is to blame rankings or ads. Before that, I check whether leads actually dropped or whether the counting dropped. Common culprits:

• A form that fails silently: a validation bug, a spam filter set too tight, a plugin update that changed behavior, a JavaScript error on one browser.
• Tracking that stopped firing: a Tag Manager trigger tied to a thank-you page URL that changed, or a container that was edited and republished.
• A redirect that broke a landing page or stripped UTM parameters and click IDs on the way through.
• Leads arriving fine on the site but failing to reach the CRM because an integration step errored.

"The site is slow." The instinct is to move hosts. Before that, I look at:

• Server resources: CPU, memory and disk under real load, and whether something else on the same server is eating them.
• Caching: whether page caching is actually on, whether it's being bypassed by cookies or query strings, and whether the CDN is serving what it should.
• Plugins: how many are running, which ones load assets on every page, which ones run heavy database queries.
• Third-party scripts: chat widgets, heatmaps, multiple analytics tags, embedded videos. These are often the heaviest part of a page and have nothing to do with hosting.

"Emails aren't arriving." The instinct is to switch providers. Before that, I check the domain's authentication:

• Is there a valid SPF record, and does it include every service that sends mail as the domain?
• Is DKIM signing enabled and passing?
• Is there a DMARC policy, and what do the reports say is failing?
• Is the site's own contact form sending through the web server with no authentication at all?

A large share of "email is broken" problems are really "the domain isn't set up to prove its mail is legitimate" problems.

The inspection checklist

When something breaks, I work through roughly this sequence. It's not glamorous. It works.

1. Pin down the symptom precisely. What exactly changed, when did it start, and who noticed? "Leads are down" becomes "form submissions recorded in GA4 dropped starting on a specific day, but only on mobile."
2. Check whether the measurement is the problem. Compare two independent sources. If GA4 shows fewer conversions but the CRM shows the same number of leads, the business is fine and the tracking is broken.
3. List what changed around the start date. Plugin and theme updates, CMS core updates, new tags, container publishes, DNS changes, SSL renewals, hosting migrations, new redirects, ad account edits. Most breakages have a change sitting right next to them.
4. Walk the path yourself. Click the ad or search result. Land on the page. Submit the form on desktop and on a phone. Confirm the thank-you state, the tracking hit, the email notification and the CRM record. Do it end to end, not in pieces.
5. Read the logs. Server error logs, PHP errors, form plugin entry logs, integration run histories in tools like Zapier or Pipedream, mail logs. Logs don't guess.
6. Isolate one variable at a time. Disable one plugin on staging. Remove one script. Test with and without cache. Changing five things at once makes it impossible to know which one mattered.
7. Fix the root cause, then verify from the outside. Re-run the same end-to-end walk from step 4. Then keep watching for a few days, because some failures are intermittent.
8. Write down what happened. A short note on the symptom, the cause and the fix saves hours the next time it happens.

Mistakes to avoid

• Fixing without reproducing. If you can't make it fail, you can't prove you made it stop failing.
• Trusting a single dashboard. Every report has plumbing. Know where the numbers come from.
• Testing only on your own machine. Your browser has cached files, saved logins and no ad blocker conflicts that your visitors might have.
• Blaming the most expensive layer first. Hosting, SEO and ad agencies get blamed because they're big line items. The cause is often a small, cheap setting.
• Declaring victory on the day of the fix. Watch the numbers for a week.

A small habit that changes a lot

The most useful habit I can recommend is to ask, every time a problem is reported: "What would have to be true for this symptom to appear, other than the obvious explanation?" Write down three answers. Then check the cheapest one first.

That one question keeps you from spending a month rebuilding something that wasn't broken. And it's how you find the missing hidden field, the stripped parameter or the expired record that was actually behind the drop.

The symptom is where you start looking. It's rarely where you finish.