Technical SEO
& performance audit
in Chicago

Performance work goes wrong most often when it is measured in the wrong place. A score from a test run on a fast connection in a data centre says little about what people on your site experience, and the second number is the one search engines use.

Lab measurement runs the page under fixed conditions and gives a repeatable answer. It is useful for comparing two builds and for finding causes. Field measurement collects what actually happened for real visitors on real devices and networks. It is noisy. It lags. And it is the record that counts.

The two disagree for reasons that are worth knowing. Field data is dominated by the slowest quarter of visitors, not the average. It mixes devices, and phone results usually drag the figure down. It reflects caching, so returning visitors look better than first-time ones. And it is grouped by page type, so one heavy template can pull a whole section below the threshold while individual tests look fine.

Our order of work follows that. Read field data first and find which page types fail. Then reproduce the failure in the lab on a throttled connection and a mid-range device, because a failure that cannot be reproduced cannot be fixed with confidence. Then change one thing at a time and re-measure.

What usually moves the numbers, in order: images delivered at the size they display in a modern format, script that blocks rendering deferred or removed, third-party tags audited and cut, layout reserved for anything that arrives late, and fonts loaded so text appears before they finish.

What rarely moves them: server upgrades on a site whose problem is client-side. Caching in front of a page that is slow because of what it loads does not help either.

The reporting is deliberately boring. Field figures by page type before and after, with the collection window stated, because the window matters. A change made today shows up in field data over the following weeks, and any claim made sooner than that is a claim about the lab.

When a Chicago company sees its pages stuck as discovered but not indexed, we run a technical audit that finds the cause and fixes it. The entry tier, an audit with fixes, starts from ~$600. Speed work and a full setup are priced as separate tiers. The schedule goes into the estimate once we have seen the site.

The Page indexing report in Search Console is where the audit starts. It is also the report people misread most. Every excluded URL carries a reason. Each reason points at a different part of the site.

Some exclusions are healthy. "Page with redirect" and "Alternate page with proper canonical tag" mean the site told Google what to do and Google agreed. A tidy site can show thousands of these. Leave them alone.

Two statuses get most of our time. "Discovered – currently not indexed" means Google knows the address and has not fetched it yet. On a small site that points to thin internal linking or a crawl queue full of junk URLs. "Crawled – currently not indexed" is harsher. Google fetched the page, read it, and decided it did not deserve a place in the index. That verdict is about the page itself: sparse copy, a near-copy of a sister page, a template with little text of its own.

Soft 404 is the quiet one. The server answers 200, yet the page looks empty. Think of an out-of-stock product with no description, or a search page with zero results. Google treats it as missing. The fix lives in the template, which should return a real 404 or carry enough content to stand.

"Excluded by noindex" needs a list check. We export those URLs and compare them with the pages the business wants found. A tag left over from staging surfaces here. It can sit on a revenue page for months.

The report lags by days. It also files URLs under the reason Google gave last time, so a fixed page stays in the old bucket until the next crawl. We run URL Inspection on a handful of addresses per status to confirm the reason is current. Validation gets requested only after the template is fixed. Validating a problem that still exists restarts the clock.

Split sitemaps make the report readable. Give products, categories, articles and locations one file each, then filter the report by sitemap. The pattern stops hiding in a total. If location pages are indexed at half the rate of articles, that ratio is the finding.

Numbers need a baseline. On the day the audit starts we record indexed and excluded counts per sitemap. After the fixes ship, the same export with the same filters shows whether pages moved from excluded to indexed. That movement is the result we report.

The output is one table. Status, count per page type, sample URLs, cause, fix, owner. Sorted by pages lost.