What ChatGPT and Perplexity See When They Visit Your Website

A solo founder asked me a question that stopped me mid-conversation:

“Does ChatGPT read my whole website, or only the page it opens? And does that really matter if customers can already use the site?”

It matters for three connected reasons: SEO discoverability, answer engine optimization, and website security.

The same public material that helps a search crawler understand your website can also reveal information to attackers. Your HTML, JavaScript, metadata, files, comments, and public endpoints are available to anyone who requests them.

That includes search engines, ChatGPT, Perplexity, curious visitors, automated scanners, and attackers.

The short answer: public means readable

ChatGPT and Perplexity do not see your website exactly as you see it in a browser.

They typically request a page and inspect the response returned by your server. Some crawlers rely heavily on the initial HTML and may not execute JavaScript to build the page. If your important content appears only after JavaScript runs, it may be difficult for them to discover, understand, or cite.

OpenAI documents separate crawlers for search and training purposes, including OAI-SearchBot and GPTBot. Perplexity also documents PerplexityBot, which follows robots.txt instructions for indexing.

This creates an important rule:

If a browser can download it without authentication, assume a crawler and an attacker can inspect it.

That does not mean every crawler reads every file. It means you should never treat a public file as private.

What AI search crawlers can read

1. Visible text and page structure

Crawlers can read text included in the server-delivered HTML, such as:

Page titles
H1, H2, and H3 headings
Paragraphs
Lists and tables
Link text
Image alt text
Product and service descriptions
Author names and publication dates

This is the foundation of both traditional SEO and answer engine optimization.

Use one clear H1. Start important sections with direct answers. Name your product, audience, location, and service precisely. Avoid vague language such as “we help them do it better.” State exactly what “it” means.

❌ “Our platform helps businesses improve their online presence.”

✅ “Our website audit checks technical SEO, content structure, AI search visibility, and security issues for small business websites.”

The second version is easier for Google, ChatGPT, Perplexity, and human readers to understand.

2. Metadata in the HTML head

Crawlers can inspect metadata that exists in the initial HTML, including:

<title>
Meta description
Canonical URL
Robots directives
Open Graph tags
Twitter or social sharing tags
Language declarations

Do not add these tags only through client-side JavaScript. If they are missing from the initial page response, some crawlers may never see them.

Write a unique title for every important page. Summarize the page accurately in the meta description. Match the title, description, H1, and visible content.

Google explains that title links can come from the <title> element and page headings, while snippets usually come from page content and sometimes the meta description. Read the Google SEO Starter Guide for the underlying principles.

3. JSON-LD and structured data

A crawler can read JSON-LD when it is present in the raw HTML:

Use accurate structured data for the page type. Depending on your website, that may include:

Organization
LocalBusiness
Article
Product
Service
BreadcrumbList
FAQPage when genuine questions and answers are visible on the page

Structured data does not guarantee rankings or citations. It gives search systems clearer context. For AEO, that context can help answer engines identify what your page represents and how its information relates to your business.

4. Robots.txt and XML sitemaps

Check these files directly:

https://yourdomain.com/robots.txt
https://yourdomain.com/sitemap.xml

robots.txt tells compliant crawlers which areas they may request. It is not a password and it is not a security control.

If you want to be discoverable in ChatGPT search, review whether OAI-SearchBot is blocked. If you want Perplexity to index your pages, review rules for PerplexityBot.

Your XML sitemap should contain canonical, indexable URLs. Remove redirects, deleted pages, staging URLs, and pages marked noindex.

A sitemap improves discovery. It does not fix thin content, broken links, missing metadata, or exposed secrets.

5. JavaScript bundles and source maps

A crawler may download JavaScript files as static text, even when it does not execute them.

That means your production bundles can reveal:

Internal API endpoints
Feature flags
Debug messages
Application routes
Service names
Comments
Accidentally embedded keys
References to private systems

Source maps deserve extra attention. A file such as main.js.map can expose the original, readable source behind a minified bundle. OWASP recommends checking JavaScript source maps for information leakage.

Do not publish source maps in production unless you have a clear reason and access restriction.

6. HTML comments and hidden content

Comments are not private:

<!-- Temporary admin route: /internal-preview -->
<!-- TODO: remove test token -->

Neither are hidden inputs, inline scripts, unused JSON blobs, or old content placed below the visible page.

Search systems may ignore some of these elements, but attackers will inspect them if they find them. Remove internal notes, test credentials, private URLs, and debugging instructions before deployment.

What attackers can see in the same public surface

Fast website builders make launching a product much easier. They also make it easy to ship files and code that were never meant to reach production.

Check for these common exposures:

Weak approach	Safer approach
❌ Upload the entire project folder	✅ Deploy only the production build directory
❌ Store secrets in frontend JavaScript	✅ Keep secrets on a protected server
❌ Leave `/.env` in the web root	✅ Store environment variables in the hosting platform
❌ Rely on `robots.txt` to hide admin pages	✅ Use authentication and authorization
❌ Publish `main.js.map` publicly	✅ Remove source maps or restrict access
❌ Leave `backup.zip` or `database.sql` online	✅ Store encrypted backups outside the public web root
❌ Use an old dependency because the site works	✅ Update packages and review known vulnerabilities
❌ Accept login forms without protection	✅ Use HTTPS, secure cookies, rate limits, and safe authentication

Exposed environment files and backups

Try opening these paths on your own domain:

/.env
/.env.local
/.env.production
/.git/HEAD
/backup.zip
/backup.sql
/database.sql
/config.php.bak

Do not test websites you do not own or have permission to assess.

A successful response containing KEY=value, database settings, source code, or account information is serious. Treat every secret in that file as compromised.

API keys in frontend code

A key inside frontend code is public by design. Renaming the variable, encoding the value, or hiding it inside a bundle does not protect it.

If you find an exposed key:

Revoke it immediately in the provider dashboard.
Create a replacement with the smallest possible permissions.
Move the request server-side if the key must remain private.
Review usage logs for unexpected requests or charges.
Remove the old value from the deployed build and repository history.

Do not wait until you understand every technical detail. Revocation is the first priority.

Unsafe login forms and cookie issues

Inspect your login and account flows for:

Login pages served over HTTP
Passwords sent to unexpected domains
Missing rate limits
Session cookies without Secure
Cookies without HttpOnly
Missing SameSite settings
Passwords stored in browser local storage
Error messages that reveal whether an account exists
Debug login routes left active

Ask your hosting provider or platform support team for the correct configuration if you are unsure. Authentication errors can expose customer accounts, even when the marketing pages look perfect.

Missing security headers and outdated software

Review response headers for protections such as:

Strict-Transport-Security
Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
A suitable Referrer-Policy

MDN explains that these headers help enforce HTTPS, limit permitted resources, prevent MIME sniffing, and reduce browser-based attacks. Configure them carefully, especially CSP, because an overly strict policy can break legitimate scripts.

Update your framework, plugins, packages, CMS, and server software. Search the project’s release notes and security advisories for known CVEs. A site can look polished while running an outdated dependency with a publicly documented weakness.

Relevant content disclosure signals

If your website uses generated text, images, audio, or video, review the disclosure rules that apply to your audience and location.

The European Commission states that transparency obligations under Article 50 of the EU AI Act apply from 2 August 2026. Certain generated or manipulated content may require clear disclosure or machine-readable marking.

If a generated image appears on your site, label it clearly. Keep the disclosure readable and close to the content. For public-interest text, document human review and editorial responsibility where applicable.

Disclosure is not only a legal question. Clear labeling also strengthens trust with customers and gives answer engines better context about the material they encounter.

A practical non-developer inspection playbook

1. View the public source

Open your page in a browser. Right-click and choose View Page Source, not only Inspect Element.

Compare the source with the page you see. Look for:

A real page title
A useful meta description
One clear H1
Main text present before scripts run
Canonical and robots tags
JSON-LD
Internal links
Comments and embedded data

If the source contains only a root element and JavaScript files, ask your platform whether it supports server-side rendering or pre-rendered pages.

2. Search for exposure patterns

Use the browser’s find function and search for:

api_key
apikey
token
secret
password
Bearer
BEGIN PRIVATE KEY
sourceMappingURL
debug
staging
localhost

Also inspect loaded JavaScript filenames and try the matching .map URL on your own site.

3. Fix the highest-risk issue first

Use this order:

Revoke exposed credentials.
Remove exposed files and debug routes.
Secure login and session settings.
Update vulnerable dependencies.
Add and test security headers.
Fix server-rendered content and metadata.
Review robots.txt and sitemap.
Add accurate JSON-LD and disclosure labels.

4. Ask for professional help when needed

Contact a security professional if you find database contents, private keys, customer records, active account credentials, unexplained admin access, payment data, or evidence of abuse.

Do not experiment on a live system after a serious exposure. Preserve logs, revoke access, and get help.

FAQ

Does ChatGPT read my entire website?

Not necessarily. It may access a specific page or search index result. Crawlers often rely on the initial HTML and may not execute JavaScript-generated content. Make important information available in server-delivered HTML.

Can Perplexity see my JavaScript?

It may download public JavaScript files as text, but that does not mean it executes them like a browser. Any credentials or internal details inside those files should be treated as exposed.

Does robots.txt protect private files?

No. It gives instructions to compliant crawlers. It does not prevent direct requests. Protect private content with authentication, access controls, and server configuration.

What is the connection between SEO, AEO, and security?

All three depend on what your website exposes and how clearly it is organized. Server-rendered content, strong metadata, clean links, and accurate schema support discoverability. Careful deployment prevents that same public surface from leaking secrets.

Is AEO different from traditional SEO?

Yes. Traditional SEO focuses on helping pages appear and perform in search results. AEO focuses on making information clear, extractable, and trustworthy when answer engines select sources for responses. Strong technical SEO remains important for both.

Your free next step

Before customers arrive, run a free SEO audit, free AEO audit, and free vulnerability check with Smart Analytics.

You can use the full audit without a login, email, paywall, or credit card. It checks SEO ranking factors, AI search optimization signals, answer structure, metadata, schema, crawlability, and security issues.

The report is available every time, and you keep the results. Specific security findings stay private in the downloadable PDF rather than appearing publicly on the screen.

Use it as a launch-readiness check for your solo-built website, then fix the highest-impact issues before search engines, customers, or attackers find them first.