How to Embed a Chatbot in a React App: Step-by-Step Guide (2026)

React is the most widely used frontend framework, powering over 40 percent of modern web applications according to the Stack Overflow 2025 Developer Survey. Adding a chatbot to a React application is not the same as dropping a script tag into a static HTML page. React's virtual DOM, component lifecycle, state management patterns, and rendering pipeline create specific challenges and opportunities that generic chatbot installation guides do not address.

The most common mistake developers make is treating a chatbot embed as a vanilla JavaScript script insertion -- pasting a script tag into index.html and hoping it works. While this approach functions, it misses the benefits of React-native integration: typed props, lifecycle-aware mounting and unmounting, state synchronization between the chatbot and your application, conditional rendering based on routes or user state, and performance optimization through lazy loading and code splitting.

This guide covers two integration approaches for React applications -- npm package installation (recommended for most projects) and script tag injection (for quick prototyping or platform constraints) -- with full code examples for both. We address the React-specific concerns that generic guides skip: how to manage chatbot lifecycle with useEffect, how to share chat state across components with Context API, how to style the chatbot widget with styled-components or Tailwind CSS, how to handle server-side rendering (SSR) with Next.js, and how to optimize bundle size and loading performance.

Every code example in this guide is compatible with React 18 and React 19, uses functional components with hooks (no class components), and follows current React best practices. Whether you are building a SaaS dashboard, an e-commerce storefront, a customer portal, or an internal tool, this guide provides the patterns you need to embed a chatbot that feels native to your React application rather than bolted on as an afterthought.

For teams that have not yet chosen a chatbot platform, our chatbot technology stack guide covers platform selection. For non-React frameworks, we have dedicated guides for Angular, Shopify, Squarespace, and GoDaddy. For general embedding across all platforms, see our how to add a chatbot to any website guide.

The npm package approach is the recommended method for React applications. It provides TypeScript types, tree-shaking support, lifecycle hooks, and proper integration with React's rendering pipeline.

Step 1: Install the Package

Most chatbot platforms offer official React SDKs or npm packages. For Conferbot, install the widget package:

npm install @conferbot/react-widget

Or with yarn:

yarn add @conferbot/react-widget

The package is typically small (15 to 40 KB gzipped) and tree-shakeable, meaning unused exports are eliminated during your build process.

Step 2: Create a ChatbotProvider Component

Wrap your application (or the relevant subtree) with a provider component that initializes the chatbot context:

<ChatbotProvider botId="YOUR_BOT_ID" theme="dark">
  <App />
</ChatbotProvider>

The provider handles initialization, authentication, and global configuration. Placing it high in your component tree makes chatbot state available to any descendant component through React Context.

Step 3: Render the Chat Widget

Add the widget component where you want the chat interface to appear (typically at the root layout level so it persists across routes):

<ChatWidget position="bottom-right" greeting="Hi! How can I help?" />

The widget component accepts props for position, greeting message, theme, language, and other configuration. Because it is a React component, you can conditionally render it based on route, user authentication state, or any other condition:

{isLoggedIn && <ChatWidget />}

Step 4: Use the Chat Hook for Programmatic Control

The npm package exposes a custom hook for programmatic interaction with the chatbot from any component in your tree:

const { open, close, sendMessage, isOpen, messages } = useChatbot();

This hook enables powerful integrations: open the chat when a user clicks a "Help" button in your UI, send context messages when users navigate to specific pages, read conversation state for analytics, and close the chat when users complete a purchase flow. The hook is the primary advantage of npm integration over script tags -- it makes the chatbot a first-class citizen of your React state tree.

Step 5: TypeScript Configuration

If your project uses TypeScript (and it should for any production React application), the npm package provides type definitions for all components, hooks, and configuration objects. This gives you autocomplete, type checking, and documentation directly in your IDE:

interface ChatbotConfig {
  botId: string;
  theme?: 'light' | 'dark' | 'auto';
  position?: 'bottom-right' | 'bottom-left';
  greeting?: string;
  language?: string;
  userData?: Record<string, unknown>;
}

TypeScript integration catches configuration errors at compile time rather than runtime -- preventing issues like misspelled prop names or incorrect data types that would silently fail in JavaScript.

The script tag approach works when an npm package is not available, when you need to load the chatbot from a CDN, or when you are prototyping quickly. In React, script injection must be handled through useEffect to respect the component lifecycle.

The Wrong Way: Editing index.html Directly

Adding a chatbot script directly to your public/index.html file works but bypasses React entirely. The chatbot loads immediately regardless of route, cannot be controlled from React components, and cannot access React state. This approach is acceptable only for the simplest use cases where the chatbot is a completely independent widget with no application integration.

The Right Way: useEffect Script Injection

Create a dedicated component that handles script loading, initialization, and cleanup:

function ChatbotWidget({ botId }) {
  const [isLoaded, setIsLoaded] = useState(false);

  useEffect(() => {
    // Prevent duplicate script injection
    if (document.getElementById('chatbot-script')) {
      setIsLoaded(true);
      return;
    }

    const script = document.createElement('script');
    script.id = 'chatbot-script';
    script.src = `https://app.conferbot.com/widget/${botId}.js`;
    script.async = true;
    script.onload = () => setIsLoaded(true);
    document.body.appendChild(script);

    // Cleanup on unmount
    return () => {
      const el = document.getElementById('chatbot-script');
      if (el) el.remove();
      // Remove widget DOM elements if API available
      window.Conferbot?.destroy?.();
    };
  }, [botId]);

  return null; // Widget renders itself via DOM manipulation
}

This component handles three critical concerns that raw script insertion misses. First, it prevents duplicate script injection by checking for an existing script element before creating a new one -- essential because React's Strict Mode in development double-invokes effects. Second, it tracks loading state so downstream components can respond to chatbot readiness. Third, it includes a cleanup function that removes the script and widget DOM elements when the component unmounts, preventing memory leaks and ghost widgets.

Handling React Strict Mode

React 18 and 19 run effects twice in development mode (Strict Mode) to help identify side-effect bugs. Without the duplicate-prevention check, your chatbot script would be injected twice, potentially creating two widget instances. The document.getElementById guard in the effect prevents this. In production builds, Strict Mode double-invocation does not occur, but your code should handle both cases gracefully.

Adding Programmatic Control via Window Object

Script-injected chatbots typically expose a global API on the window object. You can bridge this into React state with a custom hook:

function useChatbotBridge() {
  const [isOpen, setIsOpen] = useState(false);

  const open = useCallback(() => {
    window.Conferbot?.open();
    setIsOpen(true);
  }, []);

  const close = useCallback(() => {
    window.Conferbot?.close();
    setIsOpen(false);
  }, []);

  const sendMessage = useCallback((msg) => {
    window.Conferbot?.sendMessage(msg);
  }, []);

  return { open, close, sendMessage, isOpen };
}

This custom hook wraps the window-based API in React-friendly patterns (useCallback for stable references, useState for reactive UI updates). It provides a similar developer experience to the npm package's useChatbot hook, albeit without TypeScript types for the underlying API.

Managing chat state in a React application involves three layers: widget state (is the chat open or closed), conversation state (messages, user input, typing indicators), and application state (user identity, page context, and business data that informs the chatbot). Here is how to architect each layer.

Layer 1: Widget State With useState

The simplest state layer tracks whether the chat widget is open, minimized, or closed. This state drives conditional rendering and CSS transitions:

const [chatState, setChatState] = useState('closed'); // 'closed' | 'open' | 'minimized'

Widget state is local to the component that renders the chat widget. It does not need to be global unless other components need to react to chat open/close events (for example, dimming a background overlay or pausing a video when chat opens).

Layer 2: Conversation State With Context API

When multiple components need access to conversation data (for example, a notification badge showing unread messages, or a sidebar displaying recent chat history), elevate chat state to React Context:

const ChatContext = createContext(null);

function ChatProvider({ children }) {
  const [messages, setMessages] = useState([]);
  const [unreadCount, setUnreadCount] = useState(0);
  const [isTyping, setIsTyping] = useState(false);

  const value = useMemo(() => ({
    messages, unreadCount, isTyping,
    setMessages, setUnreadCount, setIsTyping
  }), [messages, unreadCount, isTyping]);

  return (
    <ChatContext.Provider value={value}>
      {children}
    </ChatContext.Provider>
  );
}

function useChat() {
  const context = useContext(ChatContext);
  if (!context) throw new Error('useChat must be used within ChatProvider');
  return context;
}

The useMemo wrapper on the context value prevents unnecessary re-renders of consuming components when unrelated state changes. This is a common React performance pattern that becomes important when chat state updates frequently (for example, during active typing with real-time indicators).

Layer 3: Application State Integration (Redux, Zustand, or Jotai)

For applications using a global state manager (Redux Toolkit, Zustand, Jotai), integrate chat events into your existing state management pattern. This enables chatbot actions to trigger application state changes and vice versa:

// Zustand store example
const useChatStore = create((set) => ({
  chatOpen: false,
  lastMessage: null,
  leadCaptured: false,
  openChat: () => set({ chatOpen: true }),
  closeChat: () => set({ chatOpen: false }),
  onLeadCapture: (data) => set({ leadCaptured: true, lastMessage: data }),
}));

This integration enables powerful patterns: when the chatbot captures a lead, update your application state to show a success banner. When a user adds an item to cart, notify the chatbot to offer related products. When chat sentiment is negative, trigger a support-escalation flag in your dashboard. The bidirectional state flow between chatbot and application creates a cohesive user experience. For more on chatbot-driven user engagement, see our conversation design masterclass.

Passing User Context to the Chatbot

The chatbot is more effective when it knows about the current user. Pass user context during initialization or updates:

// Pass user data to chatbot on auth state change
useEffect(() => {
  if (user) {
    window.Conferbot?.setUser({
      id: user.id,
      name: user.name,
      email: user.email,
      plan: user.subscription?.plan,
      signupDate: user.createdAt,
    });
  }
}, [user]);

With user context, the chatbot can personalize greetings ("Welcome back, Sarah!"), skip identification questions, and access account-specific information for support queries. This context-aware approach transforms the chatbot from a generic widget into a personalized assistant.

Chatbot widgets ship with default styles, but production applications need customization to match brand identity. Here is how to style chatbot components using React's popular CSS approaches.

Approach 1: styled-components / Emotion

CSS-in-JS libraries provide the most powerful customization for chatbot wrappers, overlays, and trigger buttons:

import styled from 'styled-components';

const ChatWrapper = styled.div`
  .cb-widget-container {
    --cb-primary: #0808EE;
    --cb-bg: #ffffff;
    --cb-text: #1a1a2e;
    --cb-radius: 16px;
    --cb-shadow: 0 8px 32px rgba(8, 8, 238, 0.15);
    font-family: 'Inter', system-ui, sans-serif;
  }

  .cb-message-bubble {
    border-radius: var(--cb-radius);
    max-width: 80%;
  }

  .cb-trigger-button {
    background: var(--cb-primary);
    width: 60px;
    height: 60px;
    border-radius: 50%;
    box-shadow: var(--cb-shadow);
    transition: transform 0.2s ease;
    &:hover { transform: scale(1.08); }
  }
`;

CSS custom properties (variables) are the preferred customization mechanism because most chatbot widgets support them natively. Defining variables at the wrapper level cascades them into the widget's internal styles without needing to override specific selectors.

Approach 2: Tailwind CSS

For Tailwind-based projects, apply utility classes to chatbot wrapper elements and use Tailwind's configuration to define chatbot-specific design tokens:

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        chatbot: {
          primary: '#0808EE',
          surface: '#f8fafc',
          text: '#1e293b',
        }
      }
    }
  }
}

Then style the wrapper component with Tailwind utilities:

<div className="fixed bottom-6 right-6 z-50">
  <ChatWidget
    className="rounded-2xl shadow-xl border border-chatbot-primary/10"
  />
</div>

Tailwind's JIT compiler generates only the CSS classes you actually use, keeping the bundle lean. The z-50 utility ensures the chatbot floats above other page content -- a common requirement that is easy to miss.

Approach 3: CSS Modules

For teams using CSS Modules (common in Create React App and Vite projects), create a scoped stylesheet for chatbot customization:

/* ChatWidget.module.css */
.wrapper :global(.cb-widget-container) {
  --cb-primary: #0808EE;
  --cb-radius: 16px;
}

.wrapper :global(.cb-trigger-button) {
  bottom: 24px;
  right: 24px;
}

The :global() selector escapes CSS Module scoping for chatbot widget classes (which are not module-scoped). This hybrid approach keeps your module scoping while targeting the widget's global CSS classes.

Dark Mode Support

Support for dark mode is increasingly expected. Configure the chatbot to respond to your application's theme state:

const { theme } = useTheme(); // Your app's theme context

<ChatWidget theme={theme === 'dark' ? 'dark' : 'light'} />

Most chatbot platforms support theme props or CSS custom properties that switch between light and dark palettes. For applications using the prefers-color-scheme media query, pass 'auto' to let the widget detect system preference automatically. For more on chatbot customization best practices, see our no-code chatbot builder guide.

React's component lifecycle and client-side routing create unique requirements for chatbot management. Here is how to handle mounting, unmounting, route changes, and conditional display.

Mounting the Chatbot Once (Avoiding Remounts)

The chatbot widget should mount once and persist across route changes. Place it outside your router's Switch/Routes component so it is not affected by route transitions:

<BrowserRouter>
  <Layout>
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/pricing" element={<Pricing />} />
    </Routes>
  </Layout>
  <ChatWidget /> {/* Outside Routes: persists across navigation */}
</BrowserRouter>

If the ChatWidget were inside a Route component, it would unmount and remount on every navigation -- destroying the conversation state and creating a poor user experience.

Route-Based Chatbot Configuration

While the widget persists, its behavior should adapt to the current route. Use React Router's useLocation hook to update chatbot context on navigation:

function RouteAwareChatbot() {
  const location = useLocation();

  useEffect(() => {
    // Update chatbot context based on current page
    const pageContext = {
      '/pricing': { intent: 'purchase', greeting: 'Questions about pricing?' },
      '/docs': { intent: 'support', greeting: 'Need help with setup?' },
      '/blog': { intent: 'explore', greeting: 'Looking for something specific?' },
    };
    const ctx = pageContext[location.pathname] || { intent: 'general' };
    window.Conferbot?.setContext(ctx);
  }, [location.pathname]);

  return <ChatWidget />;
}

This pattern informs the chatbot about page context without remounting it. The chatbot can use this context to adjust its greeting, conversation strategy, and suggested actions -- showing pricing-related prompts on the pricing page and support-related prompts in the documentation section.

Hiding the Chatbot on Specific Routes

Some routes should not display the chatbot (for example, the login page, checkout flow, or a distraction-free reading mode). Use conditional rendering based on route matching:

const HIDDEN_ROUTES = ['/login', '/signup', '/checkout'];

function ConditionalChatbot() {
  const location = useLocation();
  const shouldHide = HIDDEN_ROUTES.some(r => location.pathname.startsWith(r));

  if (shouldHide) return null;
  return <ChatWidget />;
}

Note: If you are using the script tag approach, hiding the widget requires calling the chatbot's hide API rather than unmounting the component, since script-injected widgets manage their own DOM elements.

Handling Unmount and Cleanup

When the chatbot component unmounts (route change, conditional render, or user logout), the cleanup function in useEffect should handle three things: remove any DOM elements the chatbot created outside React's tree, disconnect any event listeners or WebSocket connections, and persist conversation state if needed (to localStorage or your backend) so the conversation can resume later.

useEffect(() => {
  // Initialize chatbot
  const instance = window.Conferbot?.init({ botId });

  return () => {
    // Save conversation state before cleanup
    const state = instance?.getConversationState();
    if (state) sessionStorage.setItem('chatState', JSON.stringify(state));
    instance?.destroy();
  };
}, [botId]);

This cleanup pattern prevents memory leaks (a common issue with chatbot widgets that create persistent WebSocket connections) and enables conversation continuity across sessions. For related patterns on chatbot persistence, see our chatbot analytics guide.

Server-side rendered React applications (Next.js, Remix, Gatsby) require special handling because chatbot widgets depend on browser APIs (window, document) that do not exist during server rendering. Here is how to handle SSR correctly.

Next.js App Router (React Server Components)

In Next.js 14 and later with the App Router, chatbot components must be client components because they access browser APIs. Mark the component with the 'use client' directive:

'use client';

import { useEffect, useState } from 'react';

export function ChatbotWidget({ botId }) {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
  }, []);

  if (!mounted) return null; // Render nothing on server

  return <ChatWidget botId={botId} />;
}

The mounted state pattern is the standard approach for SSR-safe browser-dependent components. On the server, mounted is false and the component renders nothing. On the client, the effect sets mounted to true, triggering a re-render that loads the chatbot. This avoids hydration mismatches (a common SSR error where server and client output differ).

Next.js Dynamic Import With ssr: false

For Next.js Pages Router or App Router layouts, dynamic import provides a cleaner SSR bypass:

import dynamic from 'next/dynamic';

const ChatbotWidget = dynamic(
  () => import('../components/ChatbotWidget'),
  { ssr: false, loading: () => null }
);

The ssr: false option tells Next.js to skip this component entirely during server rendering and load it only on the client. This is the simplest and most reliable approach for chatbot widgets in Next.js. According to Next.js documentation on rendering strategies, client-only components are the recommended pattern for browser-dependent third-party widgets.

Remix Integration

According to the Remix browser-only documentation, Remix uses a similar pattern with its ClientOnly utility or manual useEffect mounting. Remix's convention of exporting loader functions for server data and client components for browser-dependent UI maps cleanly to chatbot integration: the chatbot configuration can come from a loader (server), while the widget renders client-only.

Gatsby Static Site Generation

Gatsby builds pages at compile time, meaning no browser APIs exist during the build process. Use Gatsby's typeof window !== 'undefined' guard or the useEffect mounting pattern described above. Gatsby's gatsby-browser.js API file is another option for loading chatbot scripts globally across all pages.

Avoiding Hydration Errors

The most common SSR bug with chatbots is a hydration mismatch: the server renders the page without the chatbot (correct), but the client's first render includes the chatbot (mismatch). React logs a hydration warning and may exhibit visual glitches. The mounted state pattern prevents this by ensuring the first client render matches the server render (both return null for the chatbot area), with the chatbot appearing only on the subsequent re-render triggered by useEffect.

For teams building on Next.js specifically, our Shopify chatbot guide covers integration patterns for Shopify Hydrogen (which uses Remix), and our general website chatbot guide covers static site generators.

A chatbot widget should enhance user experience without degrading application performance. Here are React-specific optimization techniques that keep your app fast while providing a rich chat experience.

Lazy Loading With React.lazy and Suspense

Load the chatbot component only when needed using React's built-in code splitting:

const ChatWidget = React.lazy(() => import('./ChatWidget'));

function App() {
  return (
    <Suspense fallback={null}>
      <ChatWidget />
    </Suspense>
  );
}

This splits the chatbot code into a separate bundle chunk that downloads asynchronously. The main application bundle loads faster because it does not include chatbot code. The fallback={null} ensures no loading spinner appears -- the chatbot simply appears when ready, typically within 1 to 2 seconds of page load.

Intersection Observer for Scroll-Triggered Loading

For pages where the chatbot is not immediately needed (long-form content, documentation), defer loading until the user scrolls past a threshold:

function DeferredChatbot() {
  const [shouldLoad, setShouldLoad] = useState(false);
  const sentinelRef = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => { if (entry.isIntersecting) setShouldLoad(true); },
      { rootMargin: '200px' }
    );
    if (sentinelRef.current) observer.observe(sentinelRef.current);
    return () => observer.disconnect();
  }, []);

  return (
    <>
      <div ref={sentinelRef} style={{ height: 1 }} />
      {shouldLoad && <ChatWidget />}
    </>
  );
}

The Intersection Observer watches for a sentinel element (invisible 1px div) to enter the viewport with a 200px margin. Once triggered, the chatbot loads. This ensures zero performance impact during the initial page load and critical rendering path.

Bundle Size Analysis

Monitor the chatbot's impact on your bundle size using webpack-bundle-analyzer or similar tools:

Web Vitals Impact

A properly integrated chatbot should have minimal impact on Core Web Vitals:

Largest Contentful Paint (LCP): No impact if chatbot loads asynchronously. The chatbot script should not be in the critical rendering path.

First Input Delay (FID) / Interaction to Next Paint (INP): Minimal impact (under 10ms) if the chatbot's JavaScript executes in small tasks rather than blocking the main thread during initialization.

Cumulative Layout Shift (CLS): Zero impact if the chatbot widget uses fixed/absolute positioning (which it should). The widget floats above page content without shifting existing elements.

Use Google's Web Vitals measurement tools to verify chatbot impact on your specific application. Run Lighthouse before and after chatbot integration and compare scores -- a well-implemented chatbot should show no measurable regression in Core Web Vitals scores.

Testing chatbot integration in React requires strategies for unit testing (component behavior), integration testing (chatbot + application state), and end-to-end testing (full conversation flows).

Unit Testing With React Testing Library

Test chatbot component mounting, conditional rendering, and state changes without loading the actual chatbot SDK:

// Mock the chatbot module
jest.mock('@conferbot/react-widget', () => ({
  ChatWidget: ({ botId }) => <div data-testid="chatbot" data-bot-id={botId} />,
  useChatbot: () => ({
    open: jest.fn(),
    close: jest.fn(),
    isOpen: false,
  }),
}));

test('renders chatbot on authenticated routes', () => {
  render(<App isAuthenticated={true} />);
  expect(screen.getByTestId('chatbot')).toBeInTheDocument();
});

test('hides chatbot on checkout page', () => {
  render(<MemoryRouter initialEntries={['/checkout']}><App /></MemoryRouter>);
  expect(screen.queryByTestId('chatbot')).not.toBeInTheDocument();
});

Mocking the chatbot module isolates your component logic from the chatbot SDK, making tests fast and deterministic. Test the conditions under which the chatbot appears and disappears, not the chatbot's internal behavior (which is the SDK provider's responsibility to test).

Integration Testing With Mock API

Test chatbot-to-application state interactions using mock conversation events:

test('updates app state when chatbot captures lead', async () => {
  const { result } = renderHook(() => useChatStore());
  
  // Simulate chatbot lead capture event
  act(() => {
    result.current.onLeadCapture({ email: '[email protected]' });
  });
  
  expect(result.current.leadCaptured).toBe(true);
});

End-to-End Testing With Cypress or Playwright

For full conversation flow testing, use E2E tools that can interact with the chatbot widget in a real browser:

// Cypress example
describe('Chatbot Integration', () => {
  it('opens chat and displays greeting', () => {
    cy.visit('/dashboard');
    cy.get('[data-testid="chat-trigger"]').click();
    cy.get('.cb-message-bubble').should('contain', 'How can I help');
  });
});

Common Pitfalls and Debugging

Pitfall 1: Multiple widget instances. Caused by missing cleanup in useEffect or React Strict Mode double-mount without duplicate prevention. Fix: add the script ID check shown in Method 2.

Pitfall 2: Chatbot not appearing after navigation. Caused by the ChatWidget being inside a Route component that unmounts on navigation. Fix: move ChatWidget outside the Routes component.

Pitfall 3: Hydration mismatch in SSR. Caused by rendering the chatbot during server render. Fix: use the mounted state pattern or dynamic import with ssr: false.

Pitfall 4: State not updating from chatbot events. Caused by stale closures in event handlers. Fix: use useRef for mutable references or useCallback with proper dependencies.

Pitfall 5: Performance degradation from frequent re-renders. Caused by passing unstable objects as chatbot props (new object reference on every render). Fix: memoize configuration objects with useMemo.

For broader chatbot debugging strategies, our 12 chatbot mistakes guide covers common issues across all platforms, and our hallucination prevention guide addresses AI response quality issues.

Before deploying your chatbot-integrated React application to production, verify each item on this checklist.

Performance

• Chatbot script loads asynchronously (async attribute or React.lazy)
• Bundle size impact is under 50 KB gzipped
• Core Web Vitals show no regression (run Lighthouse before/after)
• Chatbot initializes after first meaningful paint, not during critical path
• WebSocket connection establishes only when widget opens, not on page load

Functionality

• Widget appears on correct routes and is hidden on excluded routes
• Conversation persists across route navigation (widget does not remount)
• User context is passed correctly (test with authenticated and anonymous users)
• Route-based context updates work (different greetings per page)
• Cleanup runs on unmount (no memory leaks, no orphaned DOM elements)
• Works in React Strict Mode without duplicate widgets

Styling

• Widget matches brand colors, typography, and border radius
• Dark mode and light mode both work correctly
• Widget does not overlap with navigation, CTAs, or critical content
• Mobile responsiveness is verified on actual devices (not just browser simulation)
• Z-index is high enough to float above all page elements including modals

SSR and Build

• No SSR hydration errors in browser console
• Dynamic import or mounted-state pattern is in place for SSR frameworks
• Production build completes without chatbot-related warnings
• Source maps do not expose chatbot configuration or API keys

Accessibility

• Chat trigger button has proper aria-label
• Chat window is keyboard navigable (Tab, Enter, Escape to close)
• Screen readers announce new messages
• Focus management is correct (focus moves to chat on open, returns to trigger on close)

Security

• Chatbot script loaded from HTTPS CDN only
• No sensitive data (API keys, user tokens) exposed in client-side chatbot configuration
• Content Security Policy (CSP) headers allow chatbot script and WebSocket domains
• User input is sanitized by the chatbot platform (verify XSS protection)

This checklist ensures your chatbot integration is production-ready across performance, functionality, styling, SSR, accessibility, and security dimensions. For ongoing monitoring, track the chatbot's impact on your Core Web Vitals scores monthly and review conversation analytics weekly during the first month post-launch. For a comprehensive chatbot performance monitoring framework, see our chatbot analytics and metrics guide.