The email came in on a Tuesday: a small manufacturing supplier in Cleveland had watched organic visits fall off a cliff over six weeks and wanted someone to figure out why. No analytics access yet, no login credentials, no history of what the previous agency had done. Just a domain name and a one-line complaint that traffic was “half of what it used to be.”
That is the reality of freelance diagnostic work. You inherit a site you have never seen, with a problem someone else created, and a client who expects an answer before you have earned the right to poke around inside their systems. The good news is that a surprising amount of the case can be cracked from the outside using tools that cost nothing.
Open the case with nothing but a domain and a complaint
Before asking for a single password, I treat the site the way a search engine does: as a stranger arriving at the front door. The first pass is a shallow crawl of the homepage and whatever it links to, watching for status codes, canonical tags, and whether the pages even render for a bot. A free crawler will happily surface a robots.txt that quietly blocks a directory, a meta noindex someone forgot to remove after a staging push, or a sitemap that still points at a domain the client migrated off last year.
None of this proves the cause yet. But it narrows the field fast. In this case the homepage was clean, the sitemap was current, and nothing obvious screamed “deindexed.” That itself was useful information: the damage was not sitting on the front page where anyone would have spotted it.
Follow the trail of pages that dropped out of the index
A traffic drop that steep almost always means pages that used to be findable are no longer findable. So the next step is to compare what the site claims exists against what is actually indexed. I pulled the URLs from the sitemap and checked a sample of them for index status, then cross-referenced against the product and category pages the site linked internally.
The pattern emerged quickly. The blog and the top-level category pages were still indexed. The individual product pages, which had once pulled in the bulk of long-tail queries, were mostly gone. When a whole class of pages disappears together while everything above them survives, you are rarely looking at a content problem. You are looking at something structural that changed how those pages get reached or served.
Trace 301 and 302 redirect chains that swallowed the link equity
Structural clues point toward the plumbing, and the plumbing here was redirects. A recent replatforming had rewritten every product URL, and the redirects mapping old paths to new ones had been set up in a hurry. Using a free tool to trace 301 and 302 redirect chains, I fed in a batch of the old product URLs from an archived sitemap and watched what happened to each one.
The results were ugly in an instructive way. Old URLs hopped through two or three intermediate redirects before landing on the new page, and roughly a third of those hops were temporary 302s rather than permanent 301s. A 302 tells a crawler the move is temporary and the original URL should keep its standing, which means the ranking signals never fully transferred to the new address. Long chains compound the loss, and a few links terminated in soft 404s where the destination product had been discontinued without a proper replacement. Every one of those broken or leaky paths was a page that used to rank and no longer could.
Hand the client a diagnosis they can actually act on
A diagnosis is only useful if the person receiving it can do something with it. I did not hand over a raw export of forty redirect chains. I wrote three sentences: the migration replaced product URLs, the redirects were set up as temporary and often chained through dead ends, and search engines had responded by dropping the affected pages. Then I attached a prioritized list of the specific old-to-new mappings that needed to become clean, single-hop permanent redirects, with the discontinued products flagged separately for a decision about where they should point.
The client’s developer implemented the fixes in an afternoon, and the recovery came back gradually over the following weeks as pages were recrawled. What stays with me from cases like this is how little of the work required insider access at all. The evidence was public the whole time, sitting in status codes any free tool could read; the skill was in knowing which door to knock on first.