Technical SEO audit tool

The 19 technical checks only, crawlability, indexing, speed and markup. No content or policy checks.

What TMOD checks

Crawlability: robots.txt presence and rules, XML sitemap discovery and validity, internal link depth, and whether the site is reachable without JavaScript.
Indexing signals: canonical tag coverage across the crawl (80% or better passes), meta robots directives, and whether the homepage canonical is self-referential.
Markup: title tags in the 30–60 character window, meta descriptions in 70–160, Open Graph and structured data presence, and heading hierarchy.
Performance: real load time measured on the first ten pages crawled, with 3 seconds counted as fast and 6 seconds as the acceptable ceiling, plus Core Web Vitals against LCP 2.5s and CLS 0.1 and the render-blocking scripts that drive interaction delay.
Integrity: up to 40 outbound and internal links probed at concurrency 10 with an 8 second timeout, mixed-content detection on HTTPS pages, and a custom 404 probe against a path that cannot exist.
Certificates: SSL validity plus a warning when fewer than 30 days remain before expiry.

A bar chart comparing the five audits by how many of the 45 checks each runs. This audit runs 19: 19 technical.

Every check, explained

19 checks run in this audit. 8 of them have a page of their own with the exact threshold and how to fix it.

Technical & performance

Why it matters

Technical problems are silent. A canonical pointing at the wrong URL, a sitemap listing pages that 404, or a robots.txt rule blocking a directory you forgot about will quietly remove pages from the index without any error a visitor would ever notice. The site looks fine and the traffic just is not there.

This preset runs no language model at all, which makes it the fastest and cheapest audit here, and the one you can run repeatedly while you work through a fix list. Every result comes from a deterministic measurement.

It is also the right audit for a site that is not primarily content, a SaaS marketing site, a documentation site, an e-commerce catalogue. The content and policy engines assume an article-shaped site and will report misleading warnings on anything else. If your site is content-led, the SEO audit adds the eight content checks that move rankings on top of these 19.

How to fix it

01Confirm the sitemap is real before anything else

A sitemap that lists URLs which redirect, 404, or are blocked by robots.txt actively wastes crawl budget. Every URL in it should return 200 and be canonical. If your CMS generates it automatically, verify it after every structural change.

02Add self-referential canonicals site-wide

Every page should declare a canonical pointing at its own preferred URL. This is a one-line template change in most systems and it resolves the http/https, www/non-www and trailing-slash variants that otherwise look like duplicate content.

03Fix the LCP element, not the score

Find the element that renders last above the fold, usually a hero image or a web font. Give images explicit dimensions and a modern format, preload the font, and stop deferring the CSS that styles the first screen. Chasing an overall score without identifying the element that is actually slow rarely works.

04Give 404s a real page

We request a path that cannot exist and check what comes back. It must return an actual 404 status, not a 200 with a 'not found' message, a soft 404 makes every broken URL look like a real thin page to a crawler. The page itself should link back into the site so crawl equity is not lost.

The failures that quietly delete pages from the index

A handful of misconfigurations account for most of the pages that vanish from search without anyone noticing, and every one of them leaves the site looking perfectly healthy to a visitor. A noindex tag left in a template after a launch. A Disallow line inherited from staging. A canonical hardcoded to the homepage, so every article on the site declares itself a copy of the front page.

The next tier is subtler. Content that only exists after JavaScript runs, so the HTML a crawler receives is an empty shell. Redirect chains three hops deep where the final destination is a 404. Soft 404s, where missing pages answer 200 and every mistyped URL becomes an indexable near-duplicate. Pagination that loses its links behind an infinite scroll no crawler triggers.

None of these produce an error page, an alert or a support ticket. They produce a slow decline in impressions that gets blamed on an algorithm update. Running the crawl-access checks against your own live site is the cheapest way to rule the whole category out, and it takes a couple of minutes.

The directives that remove a page from Google. Each of these can delete a page from the index on its own. <meta name='robots' content='noindex'>: Removes the page. X-Robots-Tag: noindex: Same, in the HTTP header. Disallow: / in robots.txt: Blocks crawling, not indexing. <link rel='canonical' href='/other-page'>: Points ranking elsewhere. noindex + Disallow together: The noindex is never seen.

What to re-check after a redesign or a migration

A migration breaks things in bulk, and it breaks them in a specific order that is worth working through deliberately. Start with URLs: if any changed, every old address needs a 301 to its specific replacement, not a blanket redirect to the homepage, and the sitemap needs regenerating so it lists what exists now rather than what used to.

Then the host itself. A new server means a new certificate, so confirm the certificate covers the hostname and renews automatically, that http still redirects to https, and that no asset in your content is still requested over plain http. Mixed content breaks ad serving and embedded media while leaving most of the page looking fine.

Then the templates. Check an article page, a category page and a page with a table or an embed on a phone, because the responsive rules usually survive a redesign on the homepage and quietly fail on the templates nobody demoed. Finish with a link probe, since a permalink change breaks every in-content link at once and those are the links that are never in the navigation you tested.

How the crawl decides what it fetches

Knowing how the sample is built makes every number in the report easier to trust. The crawl starts at the URL you enter, fetches it, and queues the links it finds there. The sitemap is consulted as a second source of URLs, capped so that it cannot crowd out the pages your own homepage links to, and discovery continues to a depth of three clicks. A signed-in scan fetches up to 50 pages; an anonymous one runs a smaller crawl. The report header states how many pages were actually fetched, and every site-wide ratio is computed over exactly that set.

One class of page gets privileged treatment: the essential pages. When a link's address or anchor text identifies it as a privacy policy, terms, about or contact page, in any of the languages the matcher knows, it jumps the queue and is fetched even past the depth cap. A privacy policy linked only from the footer of deep article pages is still retrieved, because the checks that read it would otherwise fail a site for a page it actually has, which is the one wrong answer a sampling crawl must never give.

The crawl also has honest limits. It cannot follow links that only exist after a user interaction, so pagination behind an infinite scroll ends the trail. It does not log in, so members-only content is invisible. And a server that rate-limits or times out shrinks the sample: if the header says 11 pages on a site you know has 60, the interesting finding is why the crawler could not get further, usually a robots rule, aggressive bot protection, or a server answering slowly under parallel requests.

The practical upshot is to read the page count first and the scores second. Ratios computed over 40 fetched pages are a solid sample of a 200-page site; the same ratios over 6 pages mean the crawl needs unblocking before the audit means much. The per-check pages, the link probe and the speed measurement among them, each state their own sampling budget for the same reason: a measurement is only as good as the set it ran over.

Questions

Does it render JavaScript?

There is a dedicated JavaScript rendering check that compares the raw HTML response against what a browser produces, so you can see which content only exists after hydration. Content that is invisible without JavaScript is a real indexing risk, and this check tells you how much of your page falls into that category.

Why only 40 links for the broken-link check?

Checking every link on every crawled page means thousands of outbound requests against third-party servers, which is slow and impolite. We sample 40 links at concurrency 10 with an 8-second timeout each. That reliably surfaces systemic problems, a dead footer link on every page, a retired external resource, without hammering anyone.

It says my SSL certificate is fine but expires soon. Is that a problem?

We warn when fewer than 30 days remain. It is not a failure and it does not affect rankings today, but an expired certificate makes the entire site unreachable in most browsers, and auto-renewal fails more often than people expect. The warning exists so it is on your radar before it becomes an outage.

Can I run this on a staging site?

Only if it is publicly reachable over the internet. The crawler runs from our servers, so anything behind a VPN, basic auth, an IP allowlist or a private network is unreachable. Requests to private and loopback address ranges are also blocked deliberately, so a localhost URL will always fail.