We Audited Our Own Structured Data. Here’s What We Found.

It’s easy to tell other people to check their structured data. Turning that advice on your own site is a different exercise, so we ran the same checks kant.au runs for customers against our own public pages: the homepage, the blog, and the free tools anyone can use without an account.

What we checked

We looked at every public page on kant.au for two things: whether it emits schema.org structured data as JSON-LD, and whether its title and meta description are unique to that page rather than inherited from somewhere else by default. Both are things Google Search Central explicitly recommends getting right, and both are things our own Site Analysis feature checks on every domain we monitor. This time, the domain was ours.

No third-party crawler, no external tool. We fetched each public page directly, read the rendered HTML, and checked for <script type="application/ld+json"> blocks and the contents of the <title> and meta description tags. It’s the same checklist we’d run against a customer’s domain, applied to the pages we build and ship ourselves.

Where structured data actually showed up

The homepage is well covered. It carries WebSite, Organization, SoftwareApplication, and FAQPage schema, four separate structured data blocks doing real work. The blog is covered too: the index, the category, tag, and type archive pages, and individual posts all emit Blog or BlogPosting schema.

The four free tools, the DNS Query Tool, Email Configuration Checker, Email Deliverability Test, and Security Headers Checker, had none. Zero JSON-LD on any of them. These are arguably the highest-value pages on the entire site for search, since they’re the pages most likely to be a stranger’s first interaction with kant.au rather than someone who already knows the brand, and they were the least decorated with any structured data at all.

The fix for pages like these is WebApplication schema, the schema.org type built specifically for interactive tools rather than the broader SoftwareApplication type the homepage uses for the product as a whole. Setting applicationCategory and operatingSystem on each tool gives search engines a concrete, structured description of what the page actually does, instead of leaving it to infer that from the surrounding text.

The duplicate title we didn’t notice

Two smaller issues showed up in the metadata itself, not the schema.

Every public email deliverability result page, the shareable link generated after running a test, uses the exact same title and meta description as the homepage. There’s no page-specific metadata at all, so a visitor arriving at any one of what could be thousands of individual test results sees “kant.au — Tracking the edges” in the title bar, identical to every other result page and the homepage itself. Google’s own guidance on titles and meta descriptions is specifically about avoiding exactly this kind of duplication.

The /bot page had a smaller version of the same root cause: the brand name appearing twice in a single title tag.

Expected: About Our Bot - kant.au
Rendered: About Our Bot - kant.au | kant.au

The site’s title template appends “| kant.au” to every page title automatically. The page-level title already included the brand name on its own, and the template had no way of knowing that, so it added it again.

Does this mean kant.au’s SEO was broken?

No, and that’s worth being precise about. The pages that matter most for brand search, the homepage and the blog, were solidly covered. The gaps were specifically on tool pages and one dynamic route, exactly the kind of pages that get built fast, ship without a second look at metadata, and never come up again because nobody’s manually checking a page they already know works.

That’s the actual lesson here, not that we were careless, but that structured data and metadata gaps hide specifically in the pages everyone stops thinking about once they’re live. A homepage gets redesigned every year or two, and someone eventually notices if it looks dated or reads badly in a search result. A free tool page or a dynamically generated results page can ship once and run untouched for years, doing its job perfectly from a user’s perspective while quietly missing metadata nobody’s looking at.

A quick self-audit

Match structured data to the page’s job: WebApplication for interactive tools, BlogPosting for articles, Organization and WebSite for the site as a whole. Don’t assume one schema type covers every page.
For any route with a dynamic segment, like a result page keyed by an ID, confirm it actually generates its own title and description rather than falling back to a global default.
Search your own rendered HTML for repeated brand names in a single title tag, things like “kant.au | kant.au” or a company name appearing twice separated by different punctuation. It’s a quick way to catch a title template double-applying itself.
Re-run this check periodically. Every new page shipped is a new opportunity for the same gap to reappear.

kant.au’s Site Analysis feature runs exactly this check, structured data coverage, duplicate titles, duplicate meta descriptions, continuously for every domain you monitor, which is how we found these on our own site before writing this post. Want to see what it finds on yours? Start a free 14-day trial and find out.

Google Search Central: Understand structured data
Google Search Central: Influence your title links and snippets