Technical SEO audit,
down to the evidence.

Can Google reach your pages?

The crawler reads your robots.txt and sitemap, then maps every internal link. Pages with zero inlinks are flagged as orphans, pages Google may never discover. Underlinked money pages get link-building prompts naming exact source articles.

Should each page be indexed?

Every page is checked for noindex directives, canonical targets and sitemap conflicts. A noindex on a money page is CRITICAL; the same directive on a cart page is INFO. Context decides severity, rules understand intent.

Is the server answering correctly?

Broken pages (4xx), server failures (5xx) and redirect behavior surface as the highest-priority issues they are: a page that doesn't return 200 cannot rank, full stop.

Is the site fast enough?

Oversized HTML payloads are flagged as performance risks with concrete fixes, smaller images in modern formats, deferred scripts, lazy loading. No fake speed scores, no guaranteed-ranking claims.

A technical SEO checklist, in the right order

Technical SEO is easiest when you work from the bottom up. A page cannot rank if it cannot be reached, and it cannot be reached if the server is down, so start with the most basic questions and move upward.

1. Access. The site loads over https, the certificate is valid, and robots.txt does not block anything important.
2. Status codes. Important pages return 200. Moved pages use a single permanent redirect. Missing pages return a real 404.
3. Index control. Pages you want in search have no noindex tag, and each page points to the right canonical address.
4. Discovery. A clean sitemap lists the pages you care about and the internal links connect every page to the rest of the site.
5. Rendering. Content and links appear in the HTML Google receives, not only after heavy scripts run.
6. Speed and mobile. Pages load quickly on a phone, with a viewport tag and stable layout.
7. Markup. Structured data is valid and describes what is on the page.

If something near the top of the list is broken, fix it before polishing anything below it. A perfect title tag on a page that returns an error does nothing.

Crawling and indexing, in plain words

Search engines work in stages. First they crawl: a program fetches your pages by following links and reading your sitemap. Then they render the page, much as a browser would. Then they decide whether to index it, which means storing it so it can appear in results. Finally, at search time, they rank the indexed pages for a query.

Problems at each stage look different. If Google cannot crawl a page, it never learns what is on it. If it can crawl but chooses not to index, the page is invisible in results even though it exists. If it is indexed but ranks poorly, the issue is usually content quality, relevance or competition rather than a technical fault. Knowing which stage is failing tells you where to look.

The technical problems we see most often

• A noindex tag left on after launch. Developers add it on a staging site, and it travels to production with the code. Traffic can fall to nothing within weeks.
• Canonical tags that point somewhere else. A template that sets every canonical to the home page tells Google to ignore all the other pages.
• Redirect chains and loops. Old redirects pile up over years so that a visitor passes through three or four hops before reaching the page.
• Soft 404s. Missing pages that answer with a 200 status and a friendly message confuse crawlers and waste crawl effort.
• Blocked resources. A robots.txt rule that blocks CSS or JavaScript stops Google from seeing the page as a visitor does.
• Duplicate hostnames. The site answers on both www and non-www, or on both http and https, creating two copies of everything.
• Orphan pages. Pages that no other page links to are rarely found and rarely trusted.

Each of these has a glossary page explaining the fix. Browse them in the SEO check glossary.

Where Core Web Vitals fit

Core Web Vitals are Google's measures of real-world page experience. Largest Contentful Paint measures how long the main content takes to appear, and Google considers 2.5 seconds or less good. Interaction to Next Paint measures how quickly the page responds to input, with 200 milliseconds or less considered good. Cumulative Layout Shift measures unexpected movement, where 0.1 or less is good.

They are a ranking signal, but a modest one. Relevance and content quality come first. Treat speed as something that protects your visitors and conversions, and as a tiebreaker between pages of similar quality. The most common fixes are simple: compress and resize images, serve text with gzip or brotli, cache static files, load scripts with defer, and give images explicit width and height so the layout does not jump.

A safe workflow for fixing issues

Technical changes can cause damage when applied carelessly, so use a repeatable process. Change one thing at a time. Write down what you changed and when. Test on a staging copy where possible. After the change goes live, re-run the audit to confirm that the finding has gone and that nothing new has appeared.

For risky changes such as redirects, canonical rules and robots.txt, check a sample of URLs by hand before and after. Keep a backup of the previous configuration so you can roll back quickly. If traffic drops after a change, the dated log is the first place to look.

How often should you run a technical audit?

Run one after every major change such as a redesign, migration, plugin update or new template, and then once a month as routine maintenance. Sites change when pages are added, redirected or removed, and small faults accumulate quietly. A regular audit catches them while they are cheap to fix.

Pair the audit with Google Search Console, which shows how Google itself sees your site: which pages are indexed, which are excluded and why, and how pages perform in real searches. The audit tells you what is wrong on the site, and Search Console tells you what Google has done about it.

Sources

• Google: Canonicalization
• Google: Links and crawlability
• Google: Robots meta tag

Run the free technical audit →