Adding AI Features to an Existing Website Without Rebuilding It

You rarely need a new website to add AI. You need a job the current site already creates — repeated questions, slow first drafts, clumsy search — and a safe place to run a model call. The existing templates, CMS, or PHP app can stay. What you add is an endpoint, a thin UI, and a rule about what the model is allowed to see. Rebuilds that start with “we should be an AI-first brand” usually ship late and still lack a source of truth.

Pick an insertion point, not a platform migration

Walk the live site as a customer and as staff. Public insertion points include a help-center search box, a widget on the shipping page, or a “explain this product” panel that only appears on SKU pages. Staff insertion points are often higher value: a button in the ticket tool that drafts a reply from the last message plus three policy URLs. Staff tools can tolerate a slower answer and a mandatory review. Public tools cannot.

If the site is WordPress, Shopify, or custom PHP, the integration pattern is the same: browser talks to your server; your server talks to the model. Never put the secret API key in theme JavaScript. The mechanics of that split are in OpenAI API integrations for websites; this article is about where the feature should live so you do not fight the CMS.

Inventory what you already have

1. Pages and docs that are allowed to be answers (and which ones are stale).
2. Structured data: product tables, price lists, opening hours — preferably in a database or feed, not only in a PDF.
3. Existing search, chat, or form tools you should replace rather than stack.
4. Auth: can a feature be staff-only behind the CMS login, which is often the right first version?
5. Hosting limits: timeouts, cron, and whether you can run a queue worker for slow jobs.

Stale docs will be retrieved as confidently as fresh ones. A two-hour cleanup of the help center is part of the AI project. So is deciding that some pages (drafts, legal negotiations, internal wikis) must never enter the index.

A first feature that does not require a vector database

If you have twenty well-written FAQ pages, you can start with a restricted prompt: “Answer only using the following text. If the answer is not there, say you do not know and offer contact.” Paste or fetch those pages server-side. That is not elegant at a thousand documents, but it is honest, cheap to evaluate, and it teaches the team what “grounded” means. Move to embeddings and a vector index when retrieval quality, not novelty, demands it.

Alternatively, skip public chat and add a summarizer for staff: paste a long email, get a bullet summary and a suggested reply, with the original still required reading. That feature has a clear owner, a clear review step, and no visitor-facing hallucination risk. Many small businesses should stop there for a quarter.

CMS-specific traps

Page builders love to wrap every paragraph in extra HTML. Retrieval quality drops when your “document” is a soup of shortcodes. Export clean text: title, headings, body, last updated. For Shopify, prefer store policies and product descriptions from the Admin API rather than scraping the storefront. For PHP apps, read from the same tables the site already uses for products or jobs so you cannot drift from the catalog.

UI that can fail in public

Assume the API will time out. Show a fallback: “We could not answer automatically” plus the contact form. Do not leave a blank bubble. Disable the input while a request is in flight so people do not triple-submit. Store a transcript id if you will hand off to a human, so the customer does not retype. Keep the existing phone number visible; AI should not be the only door.

Existing stack	Least disruptive first add	Avoid on day one
Brochure PHP / static	Staff-only draft tool, or FAQ endpoint on one page	Sitewide chat bubble and a new SPA
WordPress	Server-side plugin or small custom plugin calling your API	A random “AI plugin” that stores your key in the database in plaintext and phones home
Shopify	App proxy or backend that reads catalog + policies	Theme JS that calls OpenAI with a secret
Custom app with login	In-app assistant scoped to the user’s own records	A bot that can see every customer’s tickets

Rollout without a big-bang launch

Ship to staff first. Then ship to a hidden URL. Then ship to one high-intent page. Watch transcripts for invented policy, prompt-injection jokes, and users asking for medical or legal advice your company should refuse. Add refusals as explicit instructions and as retrieval filters. Only then consider the global widget, and only if the page-level version is boringly reliable.

• Write ten “must answer” and ten “must refuse” questions before coding the UI.
• Log model, prompt version, and retrieved chunk ids so you can debug a bad answer.
• Set a monthly spend cap and an alert; a leaked key or a looped client is an invoice problem.
• Document who is allowed to change the system prompt. Treat it like production code.

Scriplit adds these features through AI integration services on sites we did not necessarily originally build, as long as we can put a server-side component in front of the key. Describe the insertion point and whether staff-only is acceptable in a note to the AI integration contact form. A link to the live site and a copy-paste of the current FAQ is enough to start.