Is it safe to publish AI-written code? Keys, .env files and what goes public

In short

Every file you publish can be read by anyone who can open the site, and a passcode doesn't change what belongs there. Keep keys, passwords and customer data out of it.
No server does not mean no risk. Watch for pasted keys, outside scripts and text inserted with innerHTML.
If a key leaks, revoke it first. Deleting the file is not enough.

What goes public

This is the one rule to remember. When you publish a website, every file in it can be downloaded by anyone who knows the address. That includes files no page links to. Hiding code with "minifying" or "obfuscating" makes it harder to read, not secret.

File type	Public?	Example
HTML, CSS, JavaScript	Yes	An API key typed into `script.js`
Images, PDFs, downloads	Yes	A price list PDF no page links to
Config files	Yes	`config.json` with a token inside
`.env` files	Yes, if uploaded	Keys kept next to your project
Source maps (`.map`)	Yes, if uploaded	Readable copies of your original code
The `.git` folder	Yes, if uploaded	Old history with "deleted" keys in it
Files you did not publish	No	Notes, drafts, the rest of your project

Where secret keys hide

AI tools are good at making things work. Sometimes the quickest way is to paste a key straight into the code. Look for these:

Keys in JavaScript. A chatbot widget that calls an AI service directly from the page, with the key in the code. Anyone can copy that key and run up your bill.
.env files. Projects keep keys in a file called .env. It should stay on your computer, but it gets uploaded if you publish the whole project folder.
Config and build files. Settings files, source maps and leftover test files can hold keys or paths you did not mean to share.
The .git folder. This hidden folder holds your project's whole history, including keys that were "deleted" long ago.

Public keys are fine

Some keys are designed to sit in a web page: a Stripe publishable key (pk_...), a maps key restricted to your domain, an analytics ID. The service's docs say if a key is safe for the browser. If it says "secret" or "server-side only", or starts with sk_, it must never be in your site.

If a feature needs a secret

If a feature only works with a secret key, a plain website cannot do it safely on its own. Your options:

Use a service built for the job: a form service for contact forms, a booking tool for appointments, a hosted checkout for payments. They hold the secrets for you.
Put the secret behind a small server function somewhere that supports them, and have your page call that.
Drop the feature for now. A clear email link beats a leaked key.

Ask your AI directly: "Does this site contain any secret keys? If so, how can we do this without putting a secret in the browser?" It usually spots the problem once asked.

Scripts you load from elsewhere

Many AI-made pages pull in scripts from other websites: a font loader, an icon pack, analytics, a chat widget. Each one runs on your page with full power. It can read what visitors type and change what they see. If that other site is hacked, so is your page.

Use fewer. Ask: "Does this page really need each outside script?"
Pin the version. Use library@1.2.3, not "latest", so the file cannot change under you.
Add an integrity check where the library publishes one. The browser then refuses a file that has been altered. It looks like this:

Script with an integrity check

<script src="https://cdn.example.com/lib@1.2.3/lib.min.js" integrity="sha384-..." crossorigin="anonymous"></script>

Check widgets. Analytics, chat and booking widgets often add cookies and tracking too. Know what each one does and say so in your privacy page.

Putting text on the page safely

If your code takes text from the address bar, a form box or a visitor and puts it on the page with innerHTML, an attacker can slip in code that runs in other people's browsers. This is called cross-site scripting, or XSS. The safe habit is to insert plain text with textContent, which never runs as code.

Find unsafe text handling

Find every use of innerHTML, document.write and eval in my site. For each one, say where the text comes from. If it can come from the URL, a form or a visitor, change it to use textContent instead. Tell me what you changed.

A chatbot on your page

A chat box that talks to an AI needs a key to call the AI service. That key belongs on a server, never in your page. Two more things to know:

Prompt injection. Visitors can type instructions meant to trick the bot into ignoring yours. You cannot fully stop this.
So limit the damage. Give the bot no secrets and no actions. If it only answers questions from public text, a trick can do little harm.

Forms and personal details

Collect only what you need. A name and email is often enough. Every extra field is something you must protect.
Say where it goes. Your privacy page should say who receives the messages and why.
Do not build your own storage. A plain page cannot store messages safely. Use a form service or one built into your host.

On Page Lemon, ask your AI to "Add a contact form to my site". Messages are emailed to you and kept in your account, with no separate form service. Forms come with paid plans. See Contact forms.

Licences and accuracy

Check licences. Libraries, fonts, icons and images from outside have terms. Some need a credit, some forbid commercial use. Ask your AI to list what you use and where it came from.
Check the facts. AI can invent prices, reviews and claims. You are the one who published them.
Who owns AI-written work depends on the country and is still being settled. This is not legal advice. If it matters, ask a professional.

What not to paste into your AI

Your site is public, but your chat is not meant to be. Do not paste into it:

customer lists, orders or messages, unless you know how your AI service handles that data;
passwords, API keys or login codes, because the AI may write them into the site;
anything you would not print on a flyer.

Use placeholder names and "example@example.com" while building. Swap in the real details yourself.

A five-minute check before you share the link

Tick these off. Or hand the scanning part to your AI with the prompt below.

0 of 6 done

Publish the output, not the project. If there is a build step, publish the folder it makes (often dist or build). Otherwise make a fresh folder with only what the site needs.
Look for hidden files. On a Mac press Cmd+Shift+. in Finder; on Windows turn on "Hidden items". Remove .env, .git and anything you do not recognise.
Search for keys. Search the folder for key, secret, token and sk_. Check every match.
List outside scripts. Know every script loaded from another site, and keep only those you need.
See what a visitor sees. needs you Open the published site, use "View source" and skim the files it loads.
Check personal details. needs you Remove test data, real customer names and private phone numbers.

Read-only audit

List every external script, key-like string, innerHTML use, form action and personal detail in my site, with the file and line for each. Don't change anything.

When that is clean, run through the website launch checklist.

If a key did go public

What Page Lemon does to help

AI-made sites are often published by people who have never had to think about this, so there are a few safety nets:

.env files, .git, node_modules, source maps and private key files are skipped and never served.
Uploads are checked for well-known kinds of secret keys and private keys. If one is found, nothing from that upload is published, and you are told which file and line to fix.

These checks catch common mistakes, not every secret. Choosing what to publish still keeps your secrets safe. More in Security & trust and Publish a site.