Most WordPress chatbots appear on every page by default. That is convenient at first, but it is rarely the best choice for a finished site. A sales chatbot does not belong on a checkout page, and a support bot does not need to interrupt someone reading a privacy policy. Learning how to show a WordPress chatbot on selected pages gives you control over where visitors see it and what job it does in each place.
This guide shows wordpress chatbot specific pages targeting — how to show the bot only where it helps and hide it everywhere else.
This guide explains how to plan page targeting for a wordpress chatbot specific pages setup, choose between plugin settings and conditional placement, and test the result. You will find a visibility test matrix, common mistakes, and answers to the questions site owners ask most often. No coding is required for the main methods.
Why Show a Chatbot Only on Selected Pages
A chatbot that appears everywhere can distract visitors on pages where focus matters, such as checkout, payment, and long forms. It can also answer out of context, because the same greeting appears whether the visitor is reading a pricing page or a blog post. Finally, it loads on pages where nobody needs it, which adds work for the browser and can invite chats that lead nowhere.
Using wordpress chatbot specific pages rules keeps the chat window off your checkout and privacy pages, where it would only distract visitors.
Page targeting matches the bot to the moment. On a product page, it can answer questions about features and delivery. On a pricing page, it can explain plans. On a contact page, it can collect a message when no one is available. Each placement has a clear purpose.
Visitors also notice when a site respects their attention. A button that appears quietly where help is most useful feels professional and is less likely to drive people away.
Decide Eligible Pages
Before you touch any settings, decide which pages should show the chatbot. Start with your main page types: home, product or service pages, pricing, blog posts, help pages, contact, checkout, cart, account, login, thank you, legal pages, and landing pages used in ads.
The first step in wordpress chatbot specific pages setup is listing the pages where visitors actually need instant answers.
For each type, ask three questions. Does a visitor here need help right now? What question are they most likely to ask? What should the bot do if it cannot answer? If you cannot answer the first question with a clear yes, the bot probably does not belong there. If you can name the likely question, you can also write a better greeting for that page.
A useful starting pattern is to show the bot on the home page, product and service pages, pricing, and contact. Hide it on checkout, cart, account, login, and thank you pages. Show it on help pages only if it is trained on your help content, and hide it on legal pages. Blog posts are a judgement call. If your blog brings in future customers, a quiet button can help. If it is mainly for reading, hiding the bot keeps the experience clean. Write the plan down and keep it with your site notes.
If you have not installed a bot yet, first learn how to add an AI chatbot to WordPress.
Choose Your Targeting Method
There are three main ways to control where a chatbot appears. Start with the simplest method that works, and move to a more advanced one only if needed.
Method 1: Plugin Display Settings
Many chatbot plugins and hosted services include display rules, called visibility, display conditions, targeting, or page rules. The wording varies, so check the official documentation for your tool first.
Every wordpress chatbot specific pages setup needs one targeting method — URL rules, page lists or a plugin setting — so pick the one your tool supports.
In general, open the chatbot settings in WordPress or in the provider dashboard, find the display section, and choose whether the widget shows on all pages, only on selected pages, or on all pages except the ones you list. Add the pages you want to include or exclude, save, clear the cache, and test in a private browser window. Some tools target by page, post, category, or post type. Others target by URL pattern, such as all pages under a shop section. Patterns are powerful but need care: one that is too broad can include pages you meant to exclude, and one that is too narrow can miss new pages.
Method 2: Conditional Placement
Conditional placement means the chatbot code only loads when a condition is met. Some plugins for code snippets or headers and footers offer this feature. You paste the embed code into the plugin and set a condition, such as show only on a named page, only in a certain category, or only when the visitor is logged out.
This method is useful when your chatbot is added through an embed script rather than a WordPress plugin. Keep it simple at first: two bots are harder to maintain than one. Name each snippet clearly and review the list whenever you change your chatbot or site structure.
Method 3: Code for Precise Control
If you need precise control, you can load the chatbot script only on chosen pages using a WordPress conditional tag in a child theme or a code snippets plugin. Most beginners should not start here, and you should never edit theme files directly without a child theme and a backup. A developer can wrap the script in a condition that checks the current page. If you hire a developer, give them your page plan so they can translate it into exact conditions. Do not paste a secret API key into page HTML or a public script. Store keys in the plugin settings or provider dashboard, and use least privilege access where the provider supports it.
Most targeting features live in the chatbot plugin, so compare them in the official WordPress plugin directory.
WordPress Chatbot Specific Pages: Set Display Conditions Step by Step
Treat this as a general workflow, because exact labels depend on your tool. Check the official documentation at each step.
First, confirm your include and exclude lists. Second, open the display settings and choose an include list if the bot belongs on a few pages, or an exclude list if it belongs almost everywhere. Third, add the pages one by one. Fourth, set the widget behaviour, such as whether the window opens automatically or stays closed until clicked.
Fifth, save and clear the cache. If you use a caching plugin, a content delivery network, or server caching, the old page may still show the old behaviour. Clear each layer, then test again. Sixth, test every page type in a private window while logged out, because logged in users sometimes see different behaviour. Check mobile too. A bot that looks fine on desktop can cover a phone screen, hide a call to action, or overlap a cookie notice. Test on a real phone if you can, and check that the button does not block the menu, checkout button, or form submit button.
Page-Level Visibility Test Matrix
A test matrix turns a vague check into a repeatable task. You run through the same pages after every change and record what you see. That record helps when a problem appears later, because you can compare the current result with the last known good result. Fill in the expected behaviour from your plan before you start, then visit each page and mark any mismatch.
| Page | Expected behaviour | What to check |
|---|---|---|
| Home page | Button visible, window closed | Position, greeting, mobile layout |
| Product page | Button visible, product greeting | Greeting matches the topic |
| Pricing page | Button visible, plan help offered | No overlap with pricing table |
| Blog post | Hidden, or quiet button only | Reading is not interrupted |
| Help page | Button visible, answers first | Human handoff is easy to find |
| Contact page | Button visible, message option | Bot does not replace the form |
| Cart and checkout | Hidden | Fields and buttons fully visible |
| Thank you page | Hidden | Confirmation message is clear |
| Account page | Hidden | No button over account links |
| Privacy page | Hidden | Legal text is easy to read |
Run the matrix on desktop and mobile, while logged out, and again after clearing the cache or updating a plugin or theme that touches the chatbot. If a page fails, note the exact mismatch first, such as checkout still shows the button on mobile.
A test matrix is how you prove wordpress chatbot specific pages rules work, because you check each page instead of guessing.
Check Exclusions and Caching
Exclusions and caching cause most targeting problems. Check that your exclude list uses the correct page addresses. A trailing slash, a different spelling, or a page that moved can break a rule. If your site uses a multilingual plugin or a shop plugin, check whether the address changes for different languages or product variations.
Caching is the usual reason wordpress chatbot specific pages rules seem to fail, so clear the cache after every change.
Check for conflicts between rules. If an include rule and an exclude rule both match the same page, one will win, and which one depends on your tool. Keep rules simple: one include list or one exclude list is easier to understand and test than a mix of both.
Clear the cache in your caching plugin, your content delivery network if you use one, and your browser, then test in a private window. If the bot still appears where it should not, check whether an optimisation plugin is combining or deferring scripts. Also check whether the bot appears only when you are logged in, since some plugins show a preview to logged in users. Always test while logged out, and ask a colleague to test from a different device if you can.
When the bot does not appear at all, work through our fixes for a WordPress AI chatbot not showing.
Common Mistakes and How to Avoid Them
The first mistake is setting the rules once and never reviewing them. Sites change: new pages appear, old pages are removed, and landing pages are created for campaigns. Review your plan every few months, or whenever you publish a new section.
The most common wordpress chatbot specific pages mistake is hiding the bot from the very page where visitors ask the most questions.
The second mistake is hiding the bot where visitors need help, such as a help or pricing page, because the rule was copied from another page type. Check the intent of each page, not only its template. A help page and a legal page may share a layout but need different behaviour.
The third mistake is using a proactive pop up on every targeted page. Use a quiet button as the default, and reserve automatic opening for the one or two pages where a visitor most needs a nudge. Give the visitor a clear way to close the window, and do not reopen it on the same visit.
The fourth mistake is forgetting mobile, where a bot can overlap a button or cover a form field. The fifth is treating targeting as a substitute for good content: a bot on the right page that gives a wrong answer is still a bad experience.
If a display rule will not save, search the WordPress support forums for your plugin name and the error.
Privacy, Consent, and Human Escalation
A chatbot can collect personal data, so decide what it should ask for on each page and collect only what you need. A product page bot might need no personal data at all. A contact page bot might need a name and an email address so someone can reply. A bot should never ask for a password, and it should never ask for payment details.
Even with wordpress chatbot specific pages rules, always keep a human handoff on the pages where visitors share personal details.
Tell visitors what happens to the information they share, with a short notice near the chat window or a link to your privacy policy. An API key belongs in the plugin settings or the provider dashboard, not in page content or a public script. If a key is exposed, revoke it, create a new one, and check the logs for unusual use.
Human escalation matters on every targeted page. A visitor who cannot get an answer should be able to reach a person without repeating the whole conversation, so make the handoff easy to find and explain when a human will reply.
Limitations
Page targeting is not perfect. Some tools offer only basic include and exclude lists, without targeting by category, user role, or device. Some apply the same greeting to every page, even when the topic changes. Some load the script on every page and only hide the button, so the page still downloads the code. If performance matters, check whether your tool truly prevents loading or only hides the widget.
Targeting also depends on page addresses staying stable, so update the rules when you change a permalink or move a page, and run the matrix again.
Frequently Asked Questions
Can I hide it on checkout?
Yes, in most setups you can hide a chatbot on checkout. Add the checkout page to your exclude list, or use an include list that does not contain checkout. This is a common choice, because checkout needs full attention and a chat pop up can distract a buyer or cover a payment button. After you set the rule, test the full checkout flow on desktop and mobile while logged out. Check that no chat button appears at any step, including the cart, the payment step, and the order confirmation page. Clear the cache before you test, because a cached checkout page may still show the old behaviour. If the bot still appears, check for a second embed, such as a script in a theme setting or a tag manager, that loads the chatbot independently of the plugin rules.
Does page targeting affect speed?
Page targeting can improve speed, but only if the chatbot script truly does not load on excluded pages. If the tool only hides the button while still loading the script, the page still downloads the code and the benefit is small. To find out, measure the page before and after you change the rules, using a performance tool and the same test conditions. You can also check whether the chatbot script appears in the page source or in the browser network panel on an excluded page. If it still loads, consider a conditional placement method that prevents loading, or ask the provider whether a true conditional load is supported. On included pages the script will still load, so keep the rest of the page lean and avoid loading the bot where it adds no value.
Conclusion
Showing a WordPress chatbot only on selected pages is a simple change with a real effect. It reduces distraction, matches help to the moment, and makes the bot easier to test and maintain. Start with a written page plan, choose the simplest targeting method that fits your tool, and test every page with the visibility matrix in this guide. Review the rules when your site changes, keep the answers accurate, and always offer a clear path to a human. Your next step is to open your page plan, mark the pages where the bot belongs, and set the first display rule today.
For more help, read How to Add an AI Chatbot to WordPress (Step by Step) and How to Train a WordPress AI Chatbot on Site Content. If the widget is missing after you change the rules, see WordPress AI Chatbot Not Showing? Fix Common Issues.