LightSite AI – LLM Discovery Integration & Security Guide

Version 2.3.5 | Script 2.3.0 | September 2026

Enable AI assistants to discover, understand, and accurately represent your content.

Technical Documentation

What This Integration Does

LightSite AI adds a lightweight, clearly structured version of your business information to your website so AI assistants like ChatGPT, Gemini, Claude, Perplexity, and Copilot can better understand your business, products, services, and key pages.

The integration also helps your website communicate more clearly with AI bots and gives you visibility into how those bots interact with your content, including what they crawl, what they ignore, and which pages they consume.

LightSite operates as parallel infrastructure rather than changing or replacing your live website. That structured version is hosted separately and connected through a lightweight script and path-scoped routing. Your existing WAF and bot rules can remain in place; the four discovery endpoints are routed to LightSite.

Features

• AI Readability — Make your website easier for AI systems to read and use.
• Brand Understanding — Improve how your brand and content are understood in AI search.
• Bot Analytics — Track AI bot visits, crawling behavior, and content consumption.
• Gap Identification — Identify gaps that may limit visibility in AI answers.
• Security Preserved — Support AI accessibility while preserving your production site's security controls.

The Four Integration Components

Prerequisites

• LightSite account: https://app.lightsite.ai/auth
• Site-specific API key from the Integration Code widget
• Access to the website HTML head (or tag manager), robots.txt, and path routing configuration
• Replace every example domain and API key below with the values for that site. Never reuse the example key.

AI Sitemap Link and Discovery Script

Add these tags to the HTML head. Use the exact current code from the site's Integration Code widget. The direct API sitemap URL is a fallback if the branded path cannot be reached.

<!-- LightSite AI Discovery Integration v2.3.0 -->
<link rel="sitemap" type="application/xml" title="AI Sitemap" href="https://api.llm-discovery-api.com/functions/v1/llm-discovery/public/sitemap.xml?domain=lightsite.ai" />

<script src="https://cdn.lightsite.ai/v2.3.0/llm-delivery.js" defer data-apikey="YOUR-API-KEY"></script>

Step 2 — robots.txt

Add the discovery rules while preserving existing security policies. Place the sitemap declaration with the other Sitemap lines. Use the site's actual domain.

# ---- LightSite.ai AI Discovery ----
User-agent: *
Allow: /
Allow: /ai-sitemap.xml
Allow: /.well-known/ai-catalog.json
Allow: /.well-known/skills.json
Allow: /.well-known/openapi.json

# LightSite verification crawler
User-agent: LightSiteBot
Allow: /

# Machine-readable entry points
Agentmap: https://example.com/.well-known/ai-catalog.json
Sitemap: https://example.com/ai-sitemap.xml
# ---- LightSite.ai AI Discovery END ----

⚠️ Check any broader Disallow rules or WAF policies separately. An Allow entry alone does not override a server-side bot block.

Route Four Discovery Paths

Use either a permanent redirect (301) or a same-domain reverse proxy (200) for each path. A proxy keeps the public URL on your domain and should forward the crawler identity and original request metadata. Routing applies only to the four paths below; normal page traffic stays on your site.

Option A: 301 Redirects

For each public path, redirect to the matching endpoint at the following base URL, with the site domain as a query parameter:

https://api.llm-discovery-api.com/functions/v1/llm-discovery/public/{endpoint}?domain=example.com

Example: /ai-sitemap.xml redirects to the public sitemap endpoint. Configure all four paths in the hosting platform's routing interface.

Option B: Same-Domain 200 Reverse Proxy

Internally fetch the matching endpoint with domain=example.com&ls_proxy=1 and return its upstream response at the original path. Forward User-Agent, Accept, Accept-Language, and relevant agent identification headers. Set X-LightSite-Original-Host and X-LightSite-Original-URI. Forward the actual client IP using a trusted server-side header supported by your edge platform; do not accept a client-supplied IP header as authoritative.

// Hosting-neutral edge-handler example. Adapt to your platform's request API.
const files = {
  '/ai-sitemap.xml': 'sitemap.xml',
  '/.well-known/ai-catalog.json': 'ai-catalog.json',
  '/.well-known/openapi.json': 'openapi.json',
  '/.well-known/skills.json': 'skills.json',
};

async function handleDiscovery(request, trustedClientIp) {
  const incoming = new URL(request.url);
  const file = files[incoming.pathname];
  if (!file) return null; // Let the site's normal handler continue.
  const target = new URL(
    'https://api.llm-discovery-api.com/functions/v1/llm-discovery/public/' + file);
  target.searchParams.set('domain', 'example.com');
  target.searchParams.set('ls_proxy', '1');
  const headers = new Headers();
  for (const name of ['User-Agent', 'Accept', 'Accept-Language', 'Referer',
    'Origin', 'Sec-CH-UA', 'X-Agent-Id', 'X-Automation-Id']) {
    const value = request.headers.get(name);
    if (value) headers.set(name, value);
  }
  for (const [name, value] of request.headers) {
    const key = name.toLowerCase();
    if (key.startsWith('x-openai') || key.startsWith('x-anthropic') ||
        key.startsWith('x-ai-')) headers.set(name, value);
  }
  if (trustedClientIp) {
    headers.set('X-LightSite-Client-IP', trustedClientIp);
    headers.set('X-Real-IP', trustedClientIp);
  }
  headers.set('X-LightSite-Original-Host', incoming.host);
  headers.set('X-LightSite-Original-URI', incoming.pathname);
  const upstream = await fetch(target, { method: 'GET', headers,
    cache: 'no-store' });
  const responseHeaders = new Headers(upstream.headers);
  responseHeaders.set('Cache-Control', 'no-store');
  return new Response(upstream.body, { status: upstream.status,
    headers: responseHeaders });
}

The edge example is platform neutral. Add the platform's route binding, trusted client IP accessor and error handling before deployment. A configuration-based proxy can implement the same route mapping and header forwarding.

Verification Checklist & Troubleshooting

Verification Checklist

• The sitemap URL returns XML; all three /.well-known/ paths return JSON. Confirm the final status and content type.
• No discovery path returns a 404, a security challenge, or an HTML fallback.
• The script loads with the site's own key and its health check succeeds.
• robots.txt declares the correct sitemap and AI catalog URL.
• LightSite shows crawler reads and AI-referred visits after test traffic.
• For a 200 proxy, verify the original host, URI, User-Agent and trusted client IP reach LightSite.

Troubleshooting

Resources and Support

Legal & Policy

• Terms and Conditions
• Privacy Policy
• Data Processing Addendum

Trust & Availability

• Security and Trust
• Service Level Agreement

Account & Support

• Account: app.lightsite.ai/auth
• Support: support@lightsite.ai
• Integration Code widget in your LightSite dashboard

LightSite AI — Security Overview

For use in customer security reviews and enterprise procurement.

1. What LightSite Is (and Is Not)

LightSite is an AI search optimisation and analytics platform with two functions:

• Publishes a clean, structured version of a customer's public marketing pages for AI tools to read (/.well-known/)
• Measures how AI answer engines and AI crawlers interact with the customer's brand and website

Architecture, Tenancy & Encryption

2. Architecture

Technology Stack

Three-tier architecture (web / application / database). Database is not directly reachable from the internet.

Integration Components

3. Tenancy and Data Isolation

• PostgreSQL Row Level Security (RLS) enabled on all customer-data tables; every policy scopes rows to the authenticated principal's organisation
• Every query scoped by client_id (site) and organisation membership — cross-tenant reads are structurally impossible through the API
• Roles stored in a dedicated user_roles table, evaluated by a SECURITY DEFINER function — preventing privilege escalation through profile writes
• Edge Functions using the service role apply explicit tenant filtering; privileged operations gated by server-side role checks
• Storage buckets are private by default; object access issued through short-lived signed URLs
• Customer API keys are tenant-scoped, restricted to approved domains and endpoints, read-only, rate limited, and rotatable

4. Encryption

Access Control, Logging & Vulnerability Management

5. Authentication and Access Control

• Auth with short-lived JWT access tokens and rotating refresh tokens
• SSO with Microsoft Entra ID (Azure AD) supported
• MFA available for LightSite-native accounts
• Organisation-scoped roles (owner / member) restrict configuration and billing to workspace owner
• Machine access: crawler-facing API endpoints authenticate with per-customer API keys (lsai_* prefix), rate limited and read-only
• Internal administrative access to production limited to named personnel on a least-privilege basis

6. Logging, Audit and Monitoring

• Authentication events, administrative configuration changes and API invocations are logged
• Edge Function invocations, errors and database activity logged and retained through Supabase platform
• API key usage logged and monitored for anomalous volume

LightSite does not currently operate an automated SIEM system. LightSite commits to notifying the customer's security contact promptly if suspicious behaviour is identified; log extracts available on request.

7. Assurance, Vulnerability and Patch Management

Independent Assurance

LightSite approves pre-coordinated penetration testing by the customer or customer-appointed third party, at no charge. Attestation summaries available on request; full reports under NDA.

Ongoing Practices

• Platform runs on managed cloud services (AWS, Google Cloud); infrastructure and runtime patching handled by providers
• Application dependencies monitored and updated continuously; automated dependency and code security scanning
• Remediation targets: Critical 1–3 days, High 7 days, Medium 30 days, Low at next scheduled release
• Version-controlled development with peer review via pull requests on a protected main branch; separated dev/staging/production environments

Data Residency, Sub-Processors & Compliance

8. Data Residency, Sub-Processors and Transfers

Primary customer database hosted on AWS infrastructure in Frankfurt, Germany (eu-central-1) via Supabase.

Core App's Sub-Processors

Optional (customer-enabled only): Slack, Google Search Console, Shopify.

Transfers to AI providers: content sent consists of the customer's public page content and search-style prompts only. No personal data, credentials or non-public business data transmitted. Submitted content is not used for provider model training.

9. Use of Data for Model Training

• Customer content is NOT used to train, fine-tune or evaluate general purpose machine-learning models
• Customer content never appears in output delivered to any other customer
• Only aggregated, de-identified operational metrics used internally for service operation and improvement
• LightSite is prepared to commit to this principle contractually

10. Retention, Export and Deletion

• Retention periods for collected event data are configurable per customer
• On termination, customer data remains exportable (JSON/CSV) for 30 days
• After that window, data is deleted or irreversibly anonymised per the DPA; earlier deletion available on written request
• Published AI-facing pages and files stop being served automatically on account termination

11. Performance and Availability Impact

• Customer page traffic is never proxied through LightSite
• Optional reverse-proxy integration scoped to LightSite-specific paths only
• Tracking snippet: 42 KB, asynchronous, minimized, non-render-blocking, cookie-free, fails silently
• A LightSite outage cannot degrade or block the customer's website
• Before/after performance measurement (TTFB, LCP, Core Web Vitals) performed during staging validation

12. Compliance Posture

Verification, Bot Identification & Summary

13. Verification by the Customer

• Local verification: window.lightsiteAI.verifySetup() validates domain connection, sitemap registration, integration signals and health status
• Dashboard transparency: published AI endpoints, verification status, AI crawler activity and referral analytics
• Staging validation: every enterprise deployment should be validated in staging before production promotion, with documented go-live sign-off package

14. Bot Identification (for CDN and WAF Allow-Listing)

LightSite's crawler identifies itself unambiguously:

15. Summary

LightSite does not access your internal systems. It requires no database credentials, introduces no inbound access paths to your infrastructure, and collects no private visitor or company data. The integration connects your website to a controlled AI discovery layer built from public marketing information only. No employee data, customer data or other non-public company data is shared with LLMs or used for training. Your site's performance, CDN behaviour and WAF policies are unchanged, because your traffic never passes through us.

16. Contact

Security questions, incident reports and documentation requests: support@lightsite.ai

LightSite AI – Security Overview Version 2.0 – 6 August 2026 | Integration Guide Version 2.3.5 | Script version 2.3.0 | September 2026