Technical problems rarely make a good site rank badly. What they do is cap it. Pages that cannot be crawled cannot be indexed, pages that cannot be indexed cannot rank, and a site that splits its signals across four versions of every address is competing against itself. Fixing that does not create demand. It stops you throwing away the demand you have already earned.
This is a working checklist rather than a comprehensive one. It covers the problems that actually occur on small and mid sized business websites, in the order that finds the expensive ones first.
Crawl the site before you form an opinion
Start by crawling your own website with a tool that behaves like a search engine, following links from the homepage and recording what it finds. Several will do a few hundred URLs free, which covers most business sites entirely.
What you want out of it is a full inventory: every URL, its status code, its title and description, its canonical tag, its word count, and how many clicks it sits from the homepage. That single export answers most of the questions below and usually surfaces two or three surprises, most commonly a set of pages nobody knew were public.
Compare that inventory against your sitemap and against the indexed count in Search Console. Three numbers that should roughly agree and frequently do not: pages you think exist, pages the crawler can reach, and pages Google has stored.
Fix the status codes first
Status codes are the site telling the crawler what happened, and getting them wrong is the fastest way to waste crawl budget.
- 404 not found on a page you still link to internally. Either restore the page or update the links. Leaving them is a slow leak of authority and a bad visitor experience.
- 500 and 503 server errors. These stop crawling immediately and are the most urgent thing on any audit. Intermittent ones are usually a capacity problem at the host.
- 302 temporary redirects used for permanent moves. A 302 asks the search engine to keep the old URL. If the move is permanent, use a 301.
- Redirect chains, where A points to B points to C. Collapse them so A points directly to C. Each hop loses a little and slows the page.
- Soft 404s, where a missing page returns a success code with a not found message. The crawler is told the page is fine, so it keeps coming back.
A useful rule: fix anything a search engine has to guess about. Ambiguity is the actual cost.
Make sure one page has one address
A website is usually reachable at more than one address, and every variant is a separate page as far as a crawler is concerned. The usual culprits are http and https, www and non www, a trailing slash and no trailing slash, upper and lower case paths, and the same product reachable through several category routes.
Pick one canonical version of each page, redirect everything else to it with a 301, and declare it with a canonical tag on the page itself. Then verify the tag actually says what you think: self referencing canonicals pointing at the wrong protocol, or an entire site canonicalising to the homepage, are both common and both quietly catastrophic.
Query strings are the other half of this. Tracking parameters, filters, sort orders and session identifiers can generate thousands of near identical URLs from a handful of real pages. Canonicalise them back to the clean version.
Read your robots.txt properly, then leave it alone
This one file can remove a site from search results, and it is a single line to do it. Open yours and confirm it is not disallowing anything you need indexed. The classic disaster is a staging rule of disallow forward slash that survives the move to production.
Understand what it does and does not do. Robots.txt controls crawling, not indexing. A blocked page can still appear in results if other sites link to it, and because the crawler cannot read it, it will appear with no description. If you want a page kept out of the index, use a noindex meta tag and leave the page crawlable so the instruction can be read.
Blocking your own CSS and JavaScript is the other mistake worth checking, because a search engine that cannot load your stylesheet cannot judge whether the page is usable on a phone.
Check what the crawler actually receives
A site built to assemble itself in the browser may serve an almost empty HTML document, with the real content arriving later through JavaScript. Google can usually render that, eventually, but rendering is queued and expensive, and anything that depends on it is slower to index and more fragile.
Test it directly. Use the URL inspection tool and look at the crawled HTML, or load a page with JavaScript disabled. If your headings, body copy and internal links are missing from that view, you have found the most important item on the audit, and no amount of content or link work will compensate until it is resolved.
The same check catches content hidden behind interactions. Text that only exists after a click on a tab or an accordion is usually fine if it is present in the HTML, and invisible if it is fetched on demand.
Audit the titles and descriptions the crawl gave you
The crawl export makes this a sorting exercise rather than a page by page review. Sort by title and look for duplicates, because two pages with identical titles usually means two pages competing for the same phrase. Filter for empty titles, and for titles over about 60 characters, which will be truncated in results.
Do the same for meta descriptions. A missing description is not a ranking problem, because Google will write one from the page, but it is a lost opportunity to influence the click. Duplicated descriptions across dozens of pages usually indicate a template that was never customised.
While you are in the export, filter for pages under about 300 words. Thin pages that duplicate each other are one of the most common reasons for the crawled but not indexed status, and consolidating several weak pages into one strong one is usually the right answer.
Check the architecture, not just the pages
Click depth is the measure that matters and the one most sites fail. Any page more than three clicks from the homepage is harder to crawl, harder to find and treated as less important. Sort your crawl by depth and look at what is stranded at five or six.
Orphan pages are the related problem: pages that exist in the sitemap but have no internal links pointing at them. A crawler arriving through links alone will never find them. They are usually landing pages built for a campaign and then forgotten.
Both are linking problems rather than technical ones, and the fix is covered in internal linking and site structure.
Confirm the site works on a phone
Mobile is how the site is indexed, so the mobile version is the version that counts. What you are checking is that nothing important is missing on a small screen, because hiding content responsively is hiding it from the index too.
Check tap targets are not crowded, that text is legible without zooming, that nothing overflows horizontally, and that any interstitial or cookie banner does not cover the content on arrival. Then check speed separately on a real connection rather than on office wifi, using Core Web Vitals as the measure.
Verify the structured data still validates
Structured data breaks silently. A template change, a plugin update or a single mistyped field can invalidate markup across an entire section without anything visibly going wrong on the page. Run your key templates through a validator, and check the enhancement reports in Search Console for errors that appeared after a deploy.
The most common faults are markup describing something not present on the page, incomplete required fields, and several blocks of JSON-LD contradicting each other. The details are in how to add schema markup.
Check HTTPS is complete, not partial
Every page should be served over HTTPS and every resource on it should be too. A secure page that loads an image, script or stylesheet over plain http is mixed content, and browsers either block it outright or flag the page as not fully secure, which visitors notice.
The usual causes are hard coded absolute URLs written before the certificate was installed, and embeds from a third party that has not moved. Your crawler will list them. While you are there, confirm the certificate is not weeks from expiry and that http requests redirect to https in one hop rather than two.
Audit migrations before and after, not just after
More organic traffic has been lost to a redesign than to any algorithm update. The pattern is always the same: a new site launches, the URLs change, nobody maps the old addresses to the new ones, and several years of accumulated authority points at pages that no longer exist.
If a migration is coming, crawl the current site first and keep that export. It becomes the checklist: every URL that had traffic or links needs a 301 to its closest equivalent, not a blanket redirect to the homepage, which search engines treat as a soft 404. Afterwards, re-crawl, compare against the old export, and watch the indexing report daily for a fortnight.
Finish with a ranked list, not a report
An audit that produces a document has failed. Sort everything you found into four groups and act in that order.
- Blocking: anything stopping pages being crawled or indexed at all. Robots rules, noindex tags, server errors, empty rendered HTML. Fix this week.
- Diluting: duplicate URLs, wrong canonicals, redirect chains, thin near duplicate pages. Fix this month.
- Limiting: click depth, orphan pages, weak internal linking, missing structured data. Fix this quarter.
- Polishing: title lengths, description rewrites, image compression. Fix when convenient.
Most sites have two or three items in the first group and dozens in the fourth, and most audits spend their time on the fourth because it is easier to enumerate. Resist that. Then re-run the crawl a month later and compare, because an audit you never repeat tells you nothing about whether the fixes worked.
How Social Signals Marketing runs technical audits
We crawl, compare against Search Console, and check rendering before we look at anything cosmetic, because those three steps find the problems that cap a site. The output is a ranked fix list with an owner and an estimate against each item, not a document, and we re-crawl after the work to confirm the count moved.
See the full programme in our SEO services, read how to use Google Search Console, or contact Social Signals Marketing for a technical review of your site.
Frequently asked questions
How often should I do a technical SEO audit?
A full audit once or twice a year is enough for most business websites, with a shorter crawl after any significant change such as a redesign, a migration, a platform update or a bulk content change. The monthly habit that matters more is checking the page indexing report in Search Console, which will flag most new problems as they appear.
What is the difference between crawling and indexing?
Crawling is a search engine fetching your page. Indexing is deciding to store it and consider it for results. A page can be crawled and not indexed, which usually means Google judged it too thin, too similar to something it already has, or not well enough linked to be worth keeping. Crawling is a technical problem and indexing is usually an editorial one.
Why are my pages crawled but not indexed?
Almost always quality or duplication rather than a technical fault. The page competes with everything already stored on that subject and loses. Common causes are thin content, near duplicate pages generated by a template, pages with no internal links pointing at them, and pages that add nothing to what already ranks. Resubmitting the URL does not help. Making the page substantially better, or merging it into a stronger one, does.
Do I need paid tools to audit my site?
No. A desktop crawler will handle a few hundred URLs free, which covers most small business sites completely, and Search Console supplies the indexing data at no cost. Paid tools save time on large sites and add competitive data, but every item on this checklist can be completed without one.
Will fixing technical SEO improve my rankings?
It removes ceilings rather than creating demand. If something is blocking indexing or splitting your signals across duplicate URLs, fixing it can produce a large and fast improvement. If your technical foundation is already sound, further technical work will produce very little, and the gains will come from content, relevance and links instead. The audit's real job is telling you which of those two situations you are in.