Technical checks explained

The FixBubbles site analysis runs 32 technical checks on your site and reports the results on Apps → FixBubbles → Diagnosis. This article documents every check: what we look at, why it matters for AI visibility, what a failure usually means, and how to fix it in principle.

For the longer, strategic take on why technical execution decides AI visibility, read the in-depth article Technical SEO in the LLM era. The check sections below use the same anchors, so links from the Diagnosis page and from this article land on matching sections.

How to read a result

Each check returns one of four results:

• Pass — the check was performed and the site meets it.
• Warning — the check was performed and found something worth improving, but not broken.
• Failed — the check was performed and the site does not meet it.
• Unverifiable — we could not verify the item because the site's firewall, CDN or bot management blocked our analyzer. This is not a failure of your site's content; we simply never received the page.

If many checks come back as Unverifiable, allowlist our analyzer (user agent GeoBubblesAnalyzer/1.0, and the crawler token GeoBubblesBot) in your firewall or CDN rules, then re-run the analysis.

Checks are grouped exactly as they appear on the Diagnosis page.

AI access

Whether AI crawlers are allowed in, whether they actually receive a page, and whether the maps you publish for them are usable.

AI assistants allowed in robots.txt

We read your robots.txt and evaluate, bot by bot, whether the major AI user-agents are permitted to fetch the analyzed pages. This matters because robots.txt is the one instruction every well-behaved AI crawler reads first: a disallow line here removes you from that engine's live-search entirely, no matter how good your content is. A failure usually means an old blanket block — often added during the 2023–2024 scraping debate — or a wildcard rule that catches more agents than intended. The fix is a deliberate decision per bot rather than an inherited one: allow the engines you want visibility in, and if you block one, do it knowingly. Note that being allowed in robots.txt is permission, not proof of access — the next check tests the real thing.

AI assistants can retrieve the page

We request the page the way an AI client would and record whether a usable HTML response comes back. This is the practical counterpart to the robots.txt check: firewalls, bot-management products and rate limiters frequently block AI user-agents even when robots.txt says "allow". A failure typically shows up as a challenge page, a 403, or an empty shell instead of your content — which means the engine has nothing of yours to cite. Fixing it is usually a firewall or CDN rule change: allowlist the AI agents you decided to permit, and verify from outside your network. Where our own analyzer is blocked this way, we mark content checks as unverifiable rather than failed, because we genuinely could not see the page.

robots.txt reachable

We check that a robots.txt exists at your site root and is returned as plain text with a successful status. It sounds trivial, but it is the file every crawler tries first, and an error or HTML error page in its place makes bot behaviour unpredictable. A failure normally means the file is missing, returns a server error, or is served as an HTML page by a catch-all route. The fix is to serve a real, small, plain-text robots.txt with correct headers — and to keep it under version control so it doesn't drift.

llms.txt published

We look for an llms.txt file at your site root — a Markdown index that points AI systems at your most important content. Be clear-eyed about this one: as of 2026 there is little public evidence that llms.txt materially changes AI retrieval, and no major engine has committed to consuming it. We report it because it is cheap, low-risk optionality, not because we can promise an effect. A "fail" here simply means the file isn't there, which is not an emergency; if you want the upside, publish a short curated index of your key pages and keep it current.

Sitemap discoverable

We check whether a sitemap is announced in robots.txt or reachable at a conventional location. Sitemaps are how crawlers — classic and AI — find pages that internal links bury, and discovery is the precondition for retrieval. A failure usually means the sitemap exists but nobody told the crawlers about it, or the URL moved when the site was rebuilt. The fix is a Sitemap: line in robots.txt pointing at the canonical, absolute sitemap URL.

Sitemap valid and reachable

We fetch the announced sitemap and confirm it responds successfully and parses as valid XML with real URLs inside. A discoverable sitemap that returns a 404, HTML, or malformed XML is worse than none, because crawlers stop trusting it. Failures here are typically stale index files pointing at deleted child sitemaps, generator bugs, or an authentication layer in front of the file. Fix it by regenerating the sitemap, validating the XML, and making sure every listed URL is publicly retrievable.

Rendering & indexing

Whether your content exists in the raw HTML without JavaScript, and whether you are telling engines the page is theirs to index.

Content present without JavaScript

We compare the substantive text in the raw HTML response against what the page shows once scripts have run, and report the ratio. This is the highest-stakes item in the whole analysis: if the initial HTML is nearly empty, most AI crawlers see nothing to extract, and your visibility depends on AI built-in knowledge alone. A failure means your main content is client-rendered — the classic symptom of a JavaScript app without server-side rendering or prerendering. The fix in principle is to deliver the primary content in the first response: server-side rendering, static generation, or prerendering for bots. Nothing else in this list moves AI visibility as reliably.

Canonical URL

We check whether the page declares a canonical URL and whether it points at itself or somewhere sensible. Canonicals tell engines which address represents a piece of content, which is what keeps citations pointing at one stable URL instead of scattering across parameter variants. Failures are usually a missing tag, a canonical pointing at the homepage on every page, or a mismatch between http/https or www/non-www. Fix it by emitting an absolute, self-referencing canonical on every indexable page and reserving cross-canonicals for genuine duplicates.

Page is indexable

We look for signals that ask engines not to index the page — robots meta tags, X-Robots-Tag headers and equivalent directives. If a page is marked noindex, it can be excluded from the corpora that feed both classic results and AI Overviews, so no amount of content work will surface it. A failure most often comes from a staging configuration that shipped to production, or a CMS template flag set years ago. The fix is to remove the directive from pages you want visible and keep noindex for pages you deliberately hide, such as internal search results.

Search Console signals

Where you have connected Google Search Console, we read the public indexing state for the analyzed URLs — whether Google reports the page as indexed and how it was discovered. This gives an outside-in confirmation that the rest of the group is actually working, and Google's index is also the corpus AI Overviews draws on. A failure or gap here means Google either hasn't picked the page up or has excluded it, which frequently corroborates a canonical, indexability or rendering problem found above. The fix is to resolve the underlying cause, then request indexing; if the check is simply unavailable, connect Search Console so we can read it.

Content structure

Whether an engine can isolate one coherent, citable passage — and whether your markup states who you are and what the page is.

Page title length

We check that the page has a single, meaningful <title> and that its length is in a sensible range — neither empty or generic, nor so long that it gets cut off. The title is the shortest summary an engine has of the page, and it is used both in classic results and as a label when a source is cited. A failure usually means a missing title, a template default repeated sitewide, or keyword stuffing that pushed it far past display limits. Fix it by writing one specific, human title per page that names the topic in the first few words.

Meta description

We check for the presence and reasonable length of a meta description. Engines don't have to use it, but it frequently becomes the snippet that frames your page — and it is a compact, machine-readable statement of what the page answers. Failures are typically missing descriptions, duplicated boilerplate across many pages, or truncated fragments. The fix is a one- or two-sentence description per page that states the answer the page provides rather than marketing adjectives.

Single main heading

We count the <h1> elements on the page and verify there is exactly one with real text. A single top-level heading tells a retriever what the whole document is about, which is the anchor it uses when deciding which passage belongs to which topic. A failure means either no <h1> at all — common when designs use styled <div>s — or several, often because a template and a content block both emit one. Fix it by reserving <h1> for the page's subject and demoting the rest.

Heading hierarchy

We inspect whether headings descend in order without skipped levels and whether sections are labelled descriptively. Heading structure is the most reliable seam a retriever has for cutting a page into passages, so an orderly hierarchy directly improves the odds that a clean, quotable chunk is extracted. Failures are usually levels chosen for visual size rather than meaning, or long stretches of text with no subheadings at all. The fix is to use headings semantically, keep each section focused on one question, and phrase subheadings the way a user would ask.

Organization structured data

We look for JSON-LD Organization markup identifying the entity behind the site — name, URL, logo and related fields. AI systems reason about entities and relationships, and this markup is the difference between an engine knowing who published a claim and having to guess. A failure means the markup is absent or lacks the identifying fields, which weakens attribution when your content is used. Fix it by publishing correct Organization markup sitewide, with the legal name you actually use elsewhere on the web.

Structured data validity

We parse every structured-data block on the page and check that it is syntactically valid and uses recognized types and properties. Malformed markup is worse than none: engines that can't parse it discard the whole block, so the effort produces zero benefit. Failures are typically JSON syntax errors, invented property names, or template variables that rendered as empty strings. Fix it by validating structured data as part of your build or release checklist rather than by hand, once.

Recommended structured data types

We check whether the page carries the structured-data types that suit its purpose — for example Article on editorial pages, FAQPage where discrete questions are answered, LocalBusiness for physical locations. The point is coverage, not volume: matching markup to page type gives engines a correct map instead of a generic one. A failure usually means only the default sitewide markup is present and page-specific types are missing. Fix it by deciding one primary type per page template and implementing it consistently.

FAQ / Article structured data

We look specifically for FAQPage and Article markup, including author and date fields where applicable. These two types map unusually well onto generative queries: FAQPage mirrors the question-and-answer shape of prompts, and Article supplies the authorship and freshness context engines use to judge whether a passage is worth citing. A failure means neither type is present on content where it would apply, or the fields are there but empty. Fix it by adding the markup to question-answering and editorial pages, and keeping author and date values accurate — inaccurate markup is a trust problem, not a shortcut.

Social sharing tags

We check for the Open Graph and equivalent tags that describe the page when it is shared or previewed. These tags are a second, redundant statement of your title, description and image, and redundancy helps when a system reads one source and not another. Failures are usually missing tags, or an image reference that doesn't resolve. The fix is a small, consistent set of sharing tags emitted by your page template, matching the real title and description.

Content depth

We measure how much substantive text the page actually contains, ignoring navigation and boilerplate. Depth is not a word-count contest, but a page with a few dozen words gives a retriever nothing self-contained to lift, so it loses to pages that answer the question fully in place. A failure usually flags a thin landing page, a page whose body is behind an interaction, or a template where the real content lives in an element we could not see. Fix it by making the page answer its question completely on the page itself — and remember that this check is only meaningful when the analyzer could read your content in the first place.

Verified profile links in structured data

We check whether your structured data links out to the profiles that corroborate your identity — for example official social, directory or knowledge-base entries. These links are how an engine connects the entity on your site to the same entity elsewhere, which strengthens confidence when deciding whether to name you as a source. A failure means no such links exist in the markup, leaving your identity claim uncorroborated. Fix it by listing only profiles you genuinely control, using their canonical URLs.

Author and expertise signals

We look for visible authorship and expertise context: a named author, a link to a profile or bio, and supporting markup. Engines increasingly favour content whose origin they can attribute to a person or organization, and anonymous pages are easier to leave out of an answer. A failure usually means content published under no byline, or a byline in prose with nothing machine-readable behind it. Fix it by naming real authors, giving them a page that describes their relevant experience, and connecting the two with markup.

Technical hygiene

Baseline signals that affect crawl completeness and corpus eligibility. Rarely decisive alone.

Secure connection (HTTPS)

We confirm the page is served over HTTPS with a valid certificate and no insecure fallbacks. Encryption is a minimum trust requirement for browsers and crawlers alike, and mixed or broken certificates cause outright fetch failures for automated clients. A failure means the page is reachable over plain HTTP, redirects inconsistently, or presents a certificate error. Fix it by serving HTTPS everywhere, redirecting HTTP once to the canonical HTTPS URL, and keeping certificates renewed automatically.

Page weight

We measure the size and composition of what the page ships as a practical stand-in for user-experience metrics we cannot measure from a single fetch. Heavy pages slow first render for users and consume crawl capacity, which means less of your site is fetched per visit. A failure typically points at oversized images, unbounded script bundles, or fonts and third-party tags loaded without limits. Fix it by compressing images, splitting or deferring scripts, and auditing third-party tags — we report page weight honestly as a proxy, not as a field measurement of Core Web Vitals.

Mobile viewport

We check for a correct viewport declaration so the page adapts to small screens. Mobile-first indexing means the mobile rendering of your page is the one that counts, and a missing viewport makes content effectively unusable on phones. A failure is almost always a missing or malformed viewport meta tag in the template. The fix is a standard viewport declaration plus a genuinely responsive layout behind it.

Favicon present

We check that a favicon is declared and retrievable. It is a small signal, but favicons appear next to cited sources in several AI and search interfaces, so a missing one costs you recognizability at the exact moment you are shown. A failure means no icon is declared, or the declared file 404s. Fix it by publishing an icon at the conventional path and referencing it explicitly.

Language and region tags

We check hreflang annotations on multilingual sites for presence, correctness and reciprocity. Correct annotations help engines serve and cite the right language version instead of mixing them, which matters when the same content exists in several markets. A failure usually means missing return links between versions, invalid language codes, or self-references that don't match the canonical. Fix it by generating hreflang programmatically from your locale list so every version points at every other, including itself.

Page language declared

We check that the <html> element declares the page's language. This is the cheapest possible signal telling a retriever which language a passage is in, and it prevents an engine from quoting your German page into an English answer. A failure means the attribute is absent, empty, or hardcoded to the wrong language on translated pages. Fix it by setting the attribute per rendered locale in your layout template.

Character encoding (UTF-8)

We confirm the page declares UTF-8 encoding. Encoding errors turn accented characters and punctuation into noise, and garbled text is text a retriever is less likely to quote. A failure normally means a missing charset declaration or a legacy encoding still configured on the server. The fix is declaring UTF-8 in the document head and serving it in the content-type header.

Accessibility basics

We run a small set of baseline accessibility checks — for example image alternative text and basic landmark structure. Accessible markup and machine-readable markup are largely the same thing: alt text and semantic landmarks describe content to any client that cannot see the rendered page, including AI crawlers. A failure usually means images without alternative text or a page built from generic containers with no semantic regions. Fix it by writing real alt text and using semantic HTML elements — this is a baseline check, not a full accessibility audit.

Web analytics tag

We check whether a recognizable analytics tag is installed. This has no direct effect on AI visibility, and we say so plainly; we report it because you cannot manage what you cannot measure, and AI-referred traffic is easy to miss without measurement in place. A failure simply means no analytics tag was detected on the analyzed page — sometimes because it loads only after consent. Fix it, if you want the data, by installing your analytics of choice consistently across templates.

Bing Webmaster verification

We look for a Bing site-verification signal. Bing's index feeds several AI assistants' live-search, so having verified access to its webmaster data gives you visibility into a corpus that matters beyond Google. A failure means no verification token was found, which affects your reporting access rather than your rankings. Fix it by verifying the site in Bing Webmaster Tools and leaving the verification token in place.