Forem: Mark McNeece

Your Website Is Invisible to ChatGPT. Here's the Fix.

Mark McNeece — Fri, 20 Mar 2026 07:18:45 +0000

AI systems are answering questions about your business right now. When someone asks ChatGPT, Claude, or Gemini about your services, they either get it right — or they hallucinate. Most of the time, they hallucinate.

The problem isn't that your site lacks content. It's that AI systems have no structured way to discover who you are, what you do, or how to refer to you.

robots.txt tells crawlers what to ignore. There's nothing equivalent that tells AI systems what to get right.

Until now.

AI Discovery Files

AI Discovery Files are a set of machine-readable files you place at the root of your website. They give AI systems a single, authoritative source of truth about your business.

Think of them as robots.txt for AI — except instead of blocking crawlers, you're telling AI systems exactly who you are.

The AI Discovery Files Specification defines 10 file types across three tiers:

Tier 1 — Essential (Start Here)

File	Purpose
`llms.txt`	Plain-text project summary for LLMs
`llms.html`	Human-readable version (same content)
`ai.txt`	Permissions and crawling preferences

Tier 2 — Identity & Brand

File	Purpose
`ai.json`	Machine-parseable permissions (JSON)
`identity.json`	Structured business identity
`brand.txt`	Naming conventions, abbreviations, terminology
`faq-ai.txt`	Pre-answered questions for AI systems

Tier 3 — Technical

File	Purpose
`developer-ai.txt`	Technical context (stack, APIs, architecture)
`robots-ai.txt`	AI-specific crawler access rules
`llm.txt`	Per-page context (like `robots.txt` but for individual URLs)

What They Look Like

Here's a minimal llms.txt:

# Acme Web Design

> Acme Web Design is a UK-based web design agency specialising in
> WordPress development for small businesses.

## Services
- WordPress website design
- E-commerce development
- Website maintenance and support

## Contact
- Website: https://www.acme-webdesign.co.uk
- Email: hello@acme-webdesign.co.uk
- Location: Manchester, UK

And the ai.txt block separately:

# AI Access Policy for acme-webdesign.co.uk

User-Agent: *
Allow-Training: no
Allow-Synthesis: yes
Allow-Citation: yes
Citation-Required: yes
Citation-Format: "Acme Web Design (https://www.acme-webdesign.co.uk)"

These are plain text files. No framework, no build step, no dependencies.

Why This Matters

Without these files, AI systems:

Guess your business name (often wrong)
Fabricate services you don't offer
Confuse you with competitors
Omit you entirely from responses

With them, every major AI system has a single source of truth. You get mentioned. You get cited. You get recommended — accurately.

This isn't SEO. This is AI visibility — making sure AI systems can discover, interpret, and correctly represent your website.

How to Implement

Option 1: Manual

Create the files by hand and drop them in your web root. The spec has examples for every file type.

Option 2: WordPress Plugin

If you're on WordPress, there's a plugin that generates all 10 files from your existing site content:

AI Discovery Files on WordPress.org

It pulls your site title, tagline, pages, and posts to auto-generate each file. You review and publish — no coding required.

Option 3: Build Your Own

The spec is open and documented. The file formats are deliberately simple — plain text and JSON. You could generate them from any CMS, static site generator, or build pipeline.

Checking Your AI Visibility

Want to see how your site scores? The AI Visibility Checker scans your domain and reports which files are present, whether they're valid, and what's missing.

Every result is deterministic — no opaque scores or prompt variance. It checks your infrastructure, not your popularity.

The Bigger Picture

We're in the early days of a shift. Search engines index pages. AI systems need to understand businesses. The sites that provide structured, machine-readable identity now will be the ones AI systems cite accurately later.

robots.txt became universal because it solved a real problem simply. AI Discovery Files solve the next one.

The AI Discovery Files Specification is open and published under CC BY 4.0. The WordPress plugin is free and open source.

Free: 3 New WordPress Plugins

Mark McNeece — Tue, 13 Jan 2026 10:21:11 +0000

3 free ways to make WordPress behave itself.

We’ve all been there. You update a plugin and your site slows to a crawl. You edit a page and the layout breaks. Or the worst one—you think you’re on the staging site, delete a page, and realise you’ve just wiped the live homepage. Panic.

I got tired of these headaches, so I built three lightweight plugins to fix them. They’re now free on the WordPress repo.

🚀 365i Queue Optimizer Stops your site choking when you upload images. It manages the background work so your dashboard stays fast, even if you’re uploading 50 products at once.

⚡ 365i Performance Optimizer Speeds up your site without breaking your design. It handles the technical stuff—like delaying code until it’s needed and hosting fonts locally—but it automatically backs off when you’re editing in Elementor. No more broken layouts.

🎨 365i Environment Indicator A simple, coloured bar at the top of your screen that screams "LIVE SITE" (in red) or "STAGING" (in orange). It sounds simple, but it stops expensive mistakes.

They are all built to be lightweight, safe, and simple!

Grab them for free here: https://wordpress.org/plugins/search/365i/

Using Schema.org's DefinedTermSet for Industry Terminology: A Case Study

Mark McNeece — Sun, 11 Jan 2026 09:20:15 +0000

How we implemented structured data for emerging AI Visibility terminology — and what we learned about making definitions machine-readable.

When we set out to publish the canonical definition of AI Visibility, we faced a question that doesn't have much documentation: How do you mark up a terminology definition page so that search engines and AI systems treat it as authoritative?

The answer turned out to be Schema.org's DefinedTermSet and DefinedTerm types — but finding practical implementation examples proved surprisingly difficult. So here's what we built, what worked, and what we'd do differently.

The Problem: Defining New Industry Terms

We'd created precise definitions for six interrelated concepts:

AI Visibility (the overarching goal)
AI Visibility Checking (infrastructure validation)
AI Discovery Files (the mechanism — llms.txt, ai.txt, etc.)
AI Visibility Tracking (outcome measurement)
AI Visibility Monitoring (real-time tracking)
AI Retrieval Testing (prompt-based observation)

These terms describe a new domain. They didn't exist in established dictionaries. We wanted search engines and AI systems to understand:

That these are formal definitions, not casual mentions
That they form a controlled vocabulary (a related set)
That each term has a unique code for citation
That there's a canonical source for each definition
That the definitions are versioned and timestamped

Why DefinedTermSet?

Schema.org's DefinedTermSet is designed for exactly this use case. From the spec:

"A set of defined terms, for example a set of categories or a classification scheme, a glossary, dictionary, or enumeration."

The related DefinedTerm type lets you mark up individual terms with properties like:

name — the term itself
description — the formal definition
termCode — a short identifier (we used AV-001 through AV-006)
inDefinedTermSet — links back to the parent set
url — canonical URL for that specific term

This creates a machine-readable knowledge structure, not just a page of text.

The Implementation

Here's the JSON-LD we deployed:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "DefinedTermSet",
      "@id": "https://www.365i.co.uk/ai-visibility-definition/#termset",
      "name": "AI Visibility Terminology",
      "description": "A controlled vocabulary for AI Visibility concepts and related terms",
      "url": "https://www.365i.co.uk/ai-visibility-definition/",
      "hasDefinedTerm": [
        {"@id": "https://www.365i.co.uk/ai-visibility-definition/#ai-visibility"},
        {"@id": "https://www.365i.co.uk/ai-visibility-definition/#ai-visibility-checking"},
        {"@id": "https://www.365i.co.uk/ai-visibility-definition/#ai-discovery-files"}
      ]
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://www.365i.co.uk/ai-visibility-definition/#ai-visibility",
      "name": "AI Visibility",
      "description": "The degree to which a website or digital entity can be discovered, correctly interpreted, accurately represented, and safely cited by AI systems including large language models, AI search engines, and retrieval-augmented generation systems.",
      "inDefinedTermSet": {"@id": "https://www.365i.co.uk/ai-visibility-definition/#termset"},
      "termCode": "AV-001",
      "url": "https://www.365i.co.uk/ai-visibility-definition/#definition-ai-visibility",
      "sameAs": "https://www.wikidata.org/wiki/Q137757467"
    }
  ]
}

Key Implementation Details

1. Using @graph for Multiple Entities
We used @graph to define multiple connected entities in a single JSON-LD block. The DefinedTermSet references each DefinedTerm via hasDefinedTerm, and each term links back via inDefinedTermSet.

2. Fragment Identifiers for Deep Linking
Each term gets its own @id with a fragment identifier (#ai-visibility, #ai-visibility-checking, etc.). This allows other pages — and other sites — to link directly to specific definitions.

3. Term Codes for Citation
The termCode property (AV-001, AV-002, etc.) gives each term a short, citable identifier. This is particularly useful for documentation, academic citation, and machine processing.

4. Wikidata sameAs Links
We created corresponding Wikidata items for each term and linked them via sameAs. This creates a bidirectional connection between our definitions and the open knowledge graph.

5. Combining with Other Schema Types
The same page also includes:

WebPage — for the page itself
TechArticle — to indicate it's a technical specification
Organization — for the publisher
BreadcrumbList — for navigation context
SpeakableSpecification — to identify key content for voice search

What We Learned

DefinedTerm vs CategoryCode
Schema.org also has CategoryCode and CategoryCodeSet, which serve a similar purpose. The distinction:

DefinedTerm is for textual definitions (glossaries, dictionaries)
CategoryCode is for classification codes (industry codes, enumerated values)

For terminology definitions with prose explanations, DefinedTerm is the better fit.

The inDefinedTermSet Issue

During validation, we discovered that inDefinedTermSet shouldn't be used on the DefinedTermSet itself — only on the individual DefinedTerm items. The Schema.org validator will flag this as a warning.

HTML Microdata Alignment

We also aligned the HTML with the JSON-LD using itemscope, itemtype, and itemprop attributes on the visible content:

<div class="definition-block" itemscope itemtype="https://schema.org/DefinedTerm">
  <meta itemprop="termCode" content="AV-001">
  <link itemprop="inDefinedTermSet" href="https://www.365i.co.uk/ai-visibility-definition/#termset">

  <h3 class="definition-term" itemprop="name">
    <dfn id="dfn-ai-visibility">AI Visibility</dfn>
  </h3>

  <p class="definition-text" itemprop="description">
    The degree to which a website or digital entity can be discovered...
  </p>
</div>

This creates redundant structured data — JSON-LD and microdata marking up the same content. Google recommends JSON-LD, but the microdata doesn't hurt and may help with semantic HTML parsing.

The Results

After deployment and indexing:

Google's Rich Results Test successfully parsed the structured data
Schema.org's validator passed with no errors (after fixing the inDefinedTermSet issue)
The Wikidata items are now live and bidirectionally linked
AI systems with web search can now discover and cite the definitions with their term codes

Recommendations for Similar Implementations

If you're defining industry terminology and want it to be machine-readable:

Use DefinedTermSet + DefinedTerm — it's the right tool for glossaries and vocabularies
Assign term codes — short identifiers make citation and referencing easier
Version your definitions — include version on the containing WebPage or TechArticle
Create Wikidata items — cross-link with sameAs to connect to the broader knowledge graph
License permissively — we used CC BY 4.0 and specified it in the schema via license
Provide machine-readable formats — we also published JSON and YAML versions

The full implementation is live at https://www.365i.co.uk/ai-visibility-definition/.

Mark McNeece is founder of 365i, an AI site identity service that helps businesses communicate accurately with AI systems. The company publishes the reference implementation of AI Visibility Checking.

Tags: schema.org, structured-data, json-ld, seo, ai-visibility, definedterm, vocabulary, web-standards