The process below is the default for a focused SEO audit at SEO Audit Services Agency. Exact days shift with site size, how quickly access is granted, and whether the scope is technical, content, backlink, migration, penalty, or ecommerce. What does not change is the sequence: we do not write findings before we can see the site properly, and we do not treat the delivery call as a substitute for the written product. If you want the shape of that product first, read What you get.
1. Scoping and kickoff
You send the site, the symptoms, and any deadlines through the contact form or email. We reply with which audit type fits, what is in and out of scope, what access we need, and a custom quote. Once you approve, we schedule kickoff. Kickoff is short. We confirm primary markets or languages, known recent releases or migrations, competitors worth watching, and who on your side owns engineering and content tickets. We also confirm how you want the register delivered (document, workbook, or both) so we are not reformatting at the end.
If the site is too large for a full crawl in the agreed window, we agree sampling rules up front: template classes, priority sections, or log-based URL sets. Sampling is not a shortcut we spring on you later. It is a scoping decision, because pretending we inspected every URL on a 500,000-page catalogue is dishonest.
2. Access setup
Most audits need read-only Google Search Console access and analytics access (GA4 or equivalent). Technical and ecommerce audits benefit from staging credentials when you have a safe environment, robots and sitemap confirmation, and, when available, server log samples. Backlink and recovery audits may need historical export access or prior disavow files. Migration audits need staging URLs, redirect map drafts, and a freeze window for pre-launch checks.
We ask for the minimum access that still lets us do the job. We do not need CMS publish rights for a diagnostic audit. When the engagement ends, we expect access to be revoked, and we will remind you to remove us from Search Console, analytics, staging, and any shared credentials. Details on how we handle that data sit in the privacy policy. Delays in access are the most common reason timelines slip, so we start the clock in earnest once the required permissions are live.
3. Crawl and analysis
With access in place, we run the crawl and pull the data sources in scope. For technical work that means crawlability, status codes, canonical clusters, redirect chains, indexation signals, rendering behaviour, structured data sanity checks, and Core Web Vitals where field or lab data supports it. For content work we cluster URLs by intent and template, score demand and quality signals, and look for cannibalization and decay. For backlinks we map referring domains, anchors, velocity, and competitor gaps. For migrations we verify staging parity and redirect coverage. For recovery we separate manual actions from algorithmic patterns and build an evidence trail. For ecommerce we pressure-test facets, PDPs, category templates, and index control.
Analysis is iterative. Early crawl noise often points to a template issue that needs a deeper sample. We do not stop at tool exports. Tools surface candidates; we confirm patterns before they become findings. If something cannot be confirmed with the access we have, it does not get written as a certainty.
4. Scoring and register build
Each confirmed issue becomes a finding with impact and effort scores, an owner hint, and a fix path. We sort the register so the top of the list is the recommended build order, not the order we discovered things. Duplicate symptoms get collapsed into pattern-level findings when that is more useful than fifty near-identical rows. The executive summary is written last, after the register is stable, so it reflects the real priority order rather than early hypotheses.
We also decide what does not make the cut. Best-practice notes that do not change outcomes for your site stay out of the main register. Out-of-scope observations may land in a short appendix so you are not surprised later, but they are not dressed up as urgent work.
5. Delivery walkthrough
You receive the written deliverable first, then we walk through it live. The call is for clarifying trade-offs, answering implementer questions, and agreeing which findings you will schedule first. It is not a substitute for reading the register. After delivery, the audit engagement is complete unless you separately engage us for implementation or a follow-up retest.
These ranges are illustrative, not service-level promises. A focused technical audit on a few thousand URLs with clean access can finish toward the short end. A migration audit across languages, or an ecommerce facet diagnosis on a large catalogue, lands toward the long end. Penalty work can move faster on evidence gathering and slower on recommending a recovery path if the history is messy. We will give you a project-specific window in the quote.
6. Optional implementation
Implementation is not included in the audit by default. After you have the register, you may ask us to help ship specific findings, write deeper specs, or retest after your team deploys. That work is scoped and quoted separately. Many clients implement everything in-house or with their existing agency. That is fine. The audit product is designed so either path works.
If you want to see the six audit types before you write to us, start at Services. If you are ready to scope, use Contact.
