Before touching code: decisions that shape everything
Integrating a language model into a website doesn’t start with installing an SDK. It starts by answering three questions that determine the rest of the checklist: what specific task the LLM solves, where inference runs, and who bears the cost per token. If you don’t have a firm answer for all three, any integration will end up being an expensive prototype that nobody maintains.
This checklist is organized by real project phases. It’s not a theoretical guide: each point includes the reason it exists and the typical failure it prevents. Some points don’t apply to every case, and I indicate that explicitly.
Phase 1. Defining the use case (don’t skip this part)
1.1. Write the task in one verifiable sentence
«Improve the user experience» is not a task. «Classify incoming support tickets into five categories with a confidence label» is. If you can’t measure whether the model’s response is correct, you can’t integrate it with any guarantees.
1.2. Check whether an LLM is really necessary
Many tasks attributed to LLMs are solved with rules, regular expressions, or a cheaper, deterministic classic classifier. An LLM shines with free-form language, ambiguity, and generation; it fails at exact calculations, strict logic, and data that changes every minute. If your case is «extract an amount from an invoice with a fixed format,» you probably don’t need a generative model.
1.3. Define the maximum acceptable cost per interaction
Prices per million tokens vary widely between providers and between models in the same family. Before integrating, calculate: average prompt length + average response length × estimated daily volume. A chatbot that receives 3,000 queries a day with 2,000-token prompts can cost more than the site’s annual hosting. Have that number before you write the first line.
Phase 2. Architecture and security
2.1. The API key never travels to the browser
This is the most common mistake and the most expensive one. Any call from client-side JavaScript exposes the key in the developer tools. The call to the provider must originate from your server or an edge function. If you need streaming to the browser, use a proxy on your backend that forwards the chunks.
2.2. Decide between an external API and a self-hosted model
External API: quick to implement, no infrastructure, but you depend on the provider’s availability and pricing, and data leaves your environment. Self-hosted model (for example, open weights served with local inference tools): full control and fixed cost, but it requires a GPU, maintenance, and know-how. For small or medium-sized websites, the API is usually the sensible decision; for sensitive data with strict residency requirements, self-hosting may be mandatory.
2.3. Filter and minimize the data you send
Before sending a prompt, remove personal identifiers, emails, and payment data that the model doesn’t need. It’s not just regulatory compliance: it reduces tokens and improves response quality by eliminating noise.
2.4. Protection against prompt injection
If the LLM processes content the user controls (comments, product descriptions, pasted text), assume that content may contain malicious instructions. Practical mitigations: separate system instructions from user content with clear delimiters, validate the output against a schema, and never let the model’s output trigger destructive actions without human confirmation.
Phase 3. Prompt and output design
3.1. Stable, versioned system instruction
Store the system prompt in a file with version control. When you change a word, you’ll be able to compare results. Prompts that live inside the code mixed with business logic are impossible to audit.
3.2. Structured output whenever possible
If the result feeds a database or an interface, request JSON with a defined schema and validate the response with a strict parser. If the model returns free text and you split by commas, you’ll break as soon as the model changes format. Most current providers offer structured output modes; use them.
3.3. Include examples in the prompt (few-shot)
Two or three examples of correct input-output usually improve the result more than paragraphs of instructions. They cost tokens, so reserve them for tasks where format matters.
3.4. Define the behavior when in doubt
Explicitly state what the model should do when it doesn’t know: return a confidence: low field, a specific phrase handing off to a human, or an empty response that your interface interprets. Without this instruction, the model will make things up with complete confidence.
Phase 4. Frontend integration
4.1. Loading states and cancellation
Generative responses take seconds. The interface needs a visible waiting state and a cancel button that aborts the request. If you use streaming, display the text as it arrives: it noticeably reduces the perception of slowness.
4.2. Component accessibility
The response container must have aria-live=»polite» so that screen readers announce the new text. Streaming without accessibility management creates broken experiences for screen reader users.
4.3. Limits on the client and on the server
Limit input length on both sides. A text field with no limit is a direct path to gigantic prompts that inflate your bill. Also add a request limit per session or per IP.
Phase 5. Quality, evaluation, and monitoring
5.1. Test set with expected responses
Before publishing, gather between 30 and 100 representative cases with the correct response annotated by hand. Run the prompt against them every time you modify it. Without this test bench, every change is a gamble.
5.2. Logging of requests and responses (carefully)
Store the prompt, the response, and the latency so you can debug. Anonymize before storing and define a retention period. A log without a retention policy becomes a liability.
5.3. Cost and latency alerts
Set a daily spending threshold that alerts you before the bill spirals out of control. An infinite loop on the client or a bot repeating requests can multiply consumption within hours.
Phase 6. SEO and visibility
6.1. Generated content doesn’t get indexed by magic
If the LLM generates pages or fragments you want to rank, they need their own URL, title, meta description, and server-side rendering. A widget that generates text inside a div after a user interaction contributes nothing to crawling.
6.2. Don’t generate massive content without review
Search engines’ quality policies discourage content produced at scale without added value. If you use the LLM to write, use it as a draft with editorial review. According to the official documentation of the major search engines, the criterion remains usefulness to the user, not the production method.
6.3. Block or mark the assistant’s internal routes
Your API endpoints and generation routes must not be crawlable or indexable. Add noindex and restrictions in robots.txt where appropriate.
Phase 7. Launch and maintenance
7.1. Progressive rollout
Enable the feature for a percentage of users first. Measure error rate, latency, and satisfaction before opening it to all traffic.
7.2. Degradation plan
What happens if the provider returns 429 or 500 errors? Define a fallback response: an unavailability message, a contact form, or a cached response. An assistant that breaks the page when the API fails is worse than having no assistant.
7.3. Periodic model review
Providers retire model versions with advance notice. Note the deprecation date of the version you use and test the migration before it becomes mandatory. Prompts fine-tuned for one version may behave differently in the next.
A specific case and its lesson
In an assistant project for a components store, the team tested the prompt with catalog questions and it worked well. When they published it, users started asking about compatibility between parts. The model answered confidently about combinations that didn’t exist in the catalog. The cause: the prompt included a sample of products, not the full catalog, and the model filled in the gaps with plausibility. The solution wasn’t a better prompt, but retrieving the relevant products from the database and passing them as context in each query. Lesson: if the answer depends on data that changes, the model needs access to that data at query time, not a static sample in the prompt.
What this checklist doesn’t solve
There’s no guarantee that the model will respond correctly to everything. LLMs hallucinate, and no configuration eliminates that behavior entirely. Nor is there a perfect prompt: what works today can degrade with the provider’s next update. And there are tasks where an LLM isn’t the right tool: exact searches, financial calculations, deterministic filters. Recognizing that in time saves budget and frustration.
If you go through these phases in order and write down the decisions for each one, you’ll have something more valuable than a working integration: you’ll have an integration you can maintain when the model, the provider, or the team changes.