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 1.5 seconds counted as fast and 3 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.
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.
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.
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.
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.