Technical SEO Audit and Crawl for Large Commerce Sites

An audit here ends with eight to twenty tickets, ranked, each written so an engineer can start it without asking me a follow-up question. A 50,000-URL crawl typically flags four to six thousand issues. The number that changes how Google reads the site is almost never more than twenty. Everything else in the engagement exists to prove which twenty. Three data sets, not one: A crawl on its own tells you what a crawler can reach, which is the least interesting of the three things worth knowing. I run Screaming Frog in rendered mode against production and, where one exists, against staging behind auth. That crawl is then read against thirty days of raw access logs (Cloudflare Logpush, CloudFront, or nginx, filtered to verified Googlebot by reverse DNS rather than by user agent string) and against the Search Console bulk export in BigQuery. Reachability, actual request behaviour, and what earned impressions. A finding that appears in one of the three and not the others drops to the bottom of the list, and the ticket says why. What the ranking is based on: Not severity labels from a tool. Each ticket carries the count of affected URLs that already receive Googlebot requests, the engineering shape of the fix (template change, CDN rule, CMS configuration, or application code), and what breaks if it ships wrong. A canonical error across 40,000 filtered category URLs that Googlebot visits twice a year sits below a single 302 in the header navigation. Tools sort by count. I sort by consequence, and I show the arithmetic so you can disagree with it. What you receive: A ranked ticket set as CSV formatted for Jira or Linear import, each ticket with a reproduction URL, current and expected response, acceptance criteria, and the owning system. A memo, usually five to eight pages, on the two or three structural problems the tickets are symptoms of. The raw crawl files, the BigQuery queries, and the log parsing scripts, so your team can rerun any of it without me. A ninety-minute working session with the engineers who will implement, not with the marketing team. Not included: Content, keyword research, backlinks, local search, competitor benchmarking. No implementation. I write the tickets, your team ships them, and that separation is deliberate: I will not be the person who both diagnoses a problem and grades the repair. No ongoing monitoring, which is a different engagement with a different rhythm. No deck. Who this is not for: Sites under about five thousand URLs. Below that, a competent in-house engineer with a crawler and an afternoon gets most of the way, and my invoice would be the most expensive line in the project for the least movement. Teams with no engineering capacity in the next two quarters, because the tickets will rot and you will have bought a document. And anyone who needs the audit to conclude that the problem is technical. Sometimes it is not. When that is the case I say so in week one rather than week five, which shortens both the engagement and the invoice. Access I need before starting: Search Console at full permission, one raw log source, and read access to the repository or a staging environment with source maps for anything client-rendered. Without code access I can still audit from the outside, but I will be inferring from output and the tickets get vaguer in exactly the places that matter. I tell you that before you sign rather than after.