Before any content or link work, we check whether search engines can actually crawl, understand and index the site. This is the order we work in and the problems that turn up most often.
Content and links get most of the attention in SEO, but they only help if search engines can reach and understand your pages in the first place. A technical audit answers that question before anyone spends money on anything else. It is unglamorous work, and it regularly finds problems that have been quietly costing a business traffic for years.
We start with indexing, because nothing else matters if pages are not in Google. In Search Console, the Pages report shows which URLs are indexed and, more usefully, why others are not. Reasons such as crawled but not indexed, duplicate without a user-selected canonical, or blocked by robots.txt each point to a different fix. We also search for the site directly and compare the number of results with the number of pages we expect. A large gap in either direction is worth investigating.
Next we read the robots.txt file and the sitemap. A robots.txt that blocks the whole site is more common than it should be, usually left over from a development stage when the site was meant to be hidden. The XML sitemap should list only the pages you want indexed, return a normal response, and be submitted in Search Console. A sitemap full of redirected or deleted URLs tells Google the site is poorly maintained.
Then we crawl the site the way a search engine would. A crawler follows every internal link and records the response code, page title, headings, canonical tag and load time for each URL. This is where the bulk of the findings appear. Broken internal links that return a 404. Redirect chains where one address sends visitors through three more before reaching the page. Duplicate titles and descriptions across dozens of pages. Pages with no heading at all. Each is small, but they add up.
Duplicate content deserves its own check. The same page reachable at both the www and non-www address, at both http and https, with and without a trailing slash, counts as several pages competing with each other. A canonical tag and a consistent redirect rule fix it, and we check that they actually agree with each other.
Mobile comes next. Google indexes the mobile version of a page, so content that appears on desktop but is hidden or missing on a phone may not count. We load key pages on a real phone and look for text that is cut off, buttons that are too close together and anything that requires zooming.
After that we look at speed and Core Web Vitals, using field data where the site has enough traffic and lab tests where it does not. We check HTTPS across the whole site, including images and scripts that still load over http and trigger warnings.
Structured data is the last technical layer. Adding the right schema markup, such as Organization, LocalBusiness, Article or Product, helps search engines understand what a page is and can make results eligible for richer displays. We validate it with Google's Rich Results Test and fix any errors, because broken markup is worse than none.
The output of an audit is not a list of two hundred warnings. It is a short list ordered by impact and effort. Blocking issues first, then things that affect many pages, then the tidy-ups. For each item we write what is wrong, where, why it matters and how to fix it, so your developer can act on it without a meeting.
If you have never had one done, an audit is one of the cheapest ways to find out whether your site is helping or hurting your search visibility.