Short answer: you cannot edit the robots.txt file on a Teachable school. Teachable manages that file for every school on the platform, and it does not offer school owners a setting to add their own bot rules. That sounds like bad news if you want GPTBot or ClaudeBot kept away from your course material, but the picture is better than it first looks. Your actual lessons sit behind a login, and AI crawlers cannot log in, so your paid course content is already out of their reach. What they can read is your public sales pages, and for those you still have a few honest options, even if none of them is a robots.txt edit.
This guide walks through exactly what Teachable lets you control, what AI crawlers can actually see on your school, and the workarounds that work, in order from simplest to strongest. Everything here is based on what Teachable documents in its own help center and what its live robots.txt file shows. Where Teachable does not document a feature, this guide says so plainly instead of guessing.
What Teachable actually lets you control
Teachable is a hosted platform. You do not get server access, you cannot upload files to the root of your domain, and there is no robots.txt editor in the admin panel. Teachable does not document any way for a school owner to edit robots.txt, and its help center has no article describing per-crawler rules for schools. That is the core fact behind everything else in this guide: the file belongs to the platform, not to you.
You can see this for yourself. Open your school's robots.txt file in a browser by adding /robots.txt to your school's address. You will get the same platform-wide file every Teachable school gets. On Teachable's own site, that file already names the major AI crawlers — GPTBot, ChatGPT-User, OAI-SearchBot, OAI-AdsBot, Google-Extended, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, and Perplexity-User — but it only blocks them from a handful of paths: /admin/, /account/, /login, /signup, /reset-password, and /search. Your course sales pages are not on that list. In other words, Teachable's default setup leaves your public pages open to AI crawlers.
What you can control is real, just different from what you might expect:
- Code snippets (Builder plan and above). Under Site > Code Snippets you can add head code to every page in your school, with separate boxes for all visitors, logged-in students, and logged-out visitors. Teachable's help center documents this as the way to add tracking pixels, analytics tools, and third-party widgets.
- Custom HTML blocks. The page editor lets you drop a Custom HTML block onto a page. This adds code to the body of that page, which is useful for embeds and styling, but it is not the right place for a meta robots tag, which belongs in the page head.
- Custom domains. On any paid plan you can connect your own domain instead of using a
.teachable.comsubdomain. This matters for branding and for Google Search Console verification, but it does not change who controls robots.txt. - Course access settings. You decide which courses are free, paid, or private, and which lessons require enrollment. This is the strongest control you have, because it decides what exists behind a login in the first place.
- Page-level SEO fields. Teachable lets you edit page titles and descriptions, which helps search visibility, but there is no documented per-page noindex toggle.
What AI crawlers can actually reach on your school
Before you spend time blocking bots, it helps to know what they can see. A Teachable school has two kinds of pages, and crawlers treat them very differently.
Your lessons are already protected by the login wall
Course lessons on Teachable require a student account and an enrollment. AI crawlers do not have accounts, cannot log in, and cannot complete a checkout. When GPTBot or ClaudeBot hits a lesson URL, it meets the same login screen a stranger would. Your video scripts, worksheets, quizzes, and lesson text are not being read by training crawlers, because the crawler never gets past the door.
This is the single most important point in this guide. If your worry is "OpenAI is training on my paid course," the answer is that your paid course content is not reachable in the first place. The login wall does the job that robots.txt would do on a self-hosted site, and it does it better, because robots.txt is only a request while a login is a real barrier.
Your public sales pages are fully exposed
The pages AI crawlers can read are the ones anyone can open without logging in: your school homepage, your course sales pages, your pricing page, and any free preview content you publish. These pages are server-rendered and indexable, and Teachable serves a sitemap that covers your public pages. That means your sales copy, your course outlines, your testimonials, and any free lesson previews you left public are all fair game for crawlers that respect robots.txt, and for the ones that do not.
For most creators, this is where the real decision sits. Your sales page is the most polished writing on your school. It describes your method, your curriculum, and your results. If you are comfortable with that copy showing up in AI answers, you may not need to block anything. If you would rather keep your wording out of training data, you need a plan for those public pages specifically, because your lessons are already safe.
The AI crawlers that matter for a Teachable school
Not every bot does the same job, and blocking the wrong one can cost you visibility you actually want. These are the crawlers you will meet most often, and what each one does according to its own provider's documentation:
- GPTBot (OpenAI) — collects content that may be used to train future OpenAI models. Blocking it keeps your pages out of training data. It has nothing to do with whether your site appears in ChatGPT search.
- OAI-SearchBot (OpenAI) — builds the index ChatGPT search draws on. If you block it, your pages will not appear in ChatGPT search answers, except as plain links. OpenAI says each of its crawler settings is independent of the others.
- ChatGPT-User (OpenAI) — fetches a page in real time when a person asks ChatGPT about it. OpenAI says robots.txt rules may not apply to it, because a person started the request.
- ClaudeBot (Anthropic) — collects content that may be used to train Claude models. Anthropic says all of its bots respect robots.txt.
- Claude-SearchBot and Claude-User (Anthropic) — handle search-style lookups and real-time fetches for Claude users. Blocking ClaudeBot does not block these.
- CCBot (Common Crawl) — gathers web data into a public archive that many AI companies use as training material. It is run by a nonprofit, and its data feeds many models indirectly.
- PerplexityBot and Perplexity-User (Perplexity) — PerplexityBot crawls for its index, while Perplexity-User fetches pages when someone asks a question. If you want to be cited in Perplexity answers, these need access.
- Google-Extended (Google) — controls whether your content is used to train Google's AI models. Blocking it does not affect your Google Search rankings; Googlebot is a separate crawler.
Notice the pattern: every major provider splits training crawlers from search crawlers. That split is what makes a sensible policy possible. You can refuse training while staying visible in AI answers, as long as you block the right names and leave the search bots alone.
Option 1: Do nothing and rely on the login wall
For many course creators, this is the right answer, and it costs nothing. If your sales pages are short and your real teaching lives behind the login, there is not much for a training crawler to take. A sales page describes a course; it is not the course. The value is in the lessons, the feedback, and the community, none of which a crawler can reach.
Doing nothing is also the honest choice if you want AI search visibility. Your sales pages are the only pages AI assistants can cite about your school. If a potential student asks ChatGPT for the best course on your topic, the answer can only mention you if OAI-SearchBot and the other search crawlers have been allowed to read your public pages. Blocking them to protect a sales page can cost you the exact discovery you built the school for.
Ask yourself one question: is there anything on your public pages that would hurt you if a future AI model had read it? If the answer is no, skip the rest of this guide and spend the time improving your course instead.
Option 2: Add a meta robots tag through Code Snippets
If you do want your public pages out of search results and AI answers, Teachable's Code Snippets feature is the only documented lever you have, and it comes with a serious catch. On the Builder plan and above, go to Site > Code Snippets and add a head code snippet with a meta robots tag:
<meta name="robots" content="noindex">That tag tells search engines and well-behaved AI crawlers not to index the page. But head code snippets on Teachable apply to every page in your school. There is no per-page setting in the snippet tool, and the separate logged-in and logged-out boxes only split by login state, not by page. So a sitewide noindex tag would remove your sales pages from Google as well as from AI crawlers. For almost every creator, that is too high a price.
There is one situation where it makes sense: a school you want fully private, where students arrive by direct link or email and you do not care about search traffic at all. In that case, the sitewide noindex tag plus your login wall gives you the strongest protection Teachable can offer. Just be sure you mean it, because your school will vanish from Google too.
Do not try to work around the sitewide problem with a Custom HTML block. That block places code in the body of one page, and a meta robots tag in the body is not valid placement. Search engines may ignore it entirely. Teachable does not document any way to add head code to a single page, so if you need page-level control, you need a different approach.
Option 3: Move your public content to a site you control
This is the strongest option, and it is the one serious course businesses usually end up with. Keep Teachable for what it is good at — hosting and selling courses — and put your public content on a site you fully control, such as a WordPress site on your own domain. On your own site, you can edit robots.txt, set per-page noindex tags, and write the exact bot rules you want.
The setup looks like this. Your marketing site lives at your main domain, with your blog, your free guides, and your sales pages. Your Teachable school lives on a subdomain such as learn.yoursite.com or courses.yoursite.com, and your sales pages link there for checkout and enrollment. On your own site, you write the robots.txt file Teachable will not let you write:
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: *
Allow: /That file blocks the four training crawlers, leaves ChatGPT search open, and allows everything else. One detail matters: a crawler follows only the group that names it, and ignores the general * group once it finds its own. That is why the training bots each get their own group with Disallow: /, while OAI-SearchBot gets its own group with Allow: /. If you put all of them in one group, the result would not be what you expect.
This approach also fixes the discovery problem. Your blog and guides can rank in Google, get cited in AI answers, and send readers to your Teachable checkout, while your course content stays behind the login on the subdomain. You get the visibility where it helps and the protection where it matters, instead of choosing one or the other for the whole school.
If you go this route, build your robots.txt file with a generator first and test it before you publish it. A single typo can block Googlebot by accident, and that mistake is easy to make and slow to notice. Our free robots.txt generator builds the file with the right syntax, and the robots.txt tester checks it against your URLs before it goes live.
Option 4: Cloudflare, and why it is not your lever here
You may have read that Cloudflare can block AI bots with a single toggle. That is true for sites where you control the Cloudflare account. Teachable schools are different. Teachable says its school domains are proxied through Cloudflare's network, which speeds up and protects requests to your school — but that Cloudflare setup belongs to Teachable, not to you. Teachable does not document any way for a school owner to add their own Cloudflare firewall rules, bot rules, or AI crawler settings to a school.
That means the usual Cloudflare advice does not apply to your Teachable school itself. You cannot turn on Cloudflare's AI crawler block for your school, because you do not hold the Cloudflare account in front of it. What you can do is put Cloudflare in front of a site you do control, such as the marketing site described in option 3, and block bots there. That works because the rules run on your account, on your domain.
Be careful with one tempting shortcut: pointing your custom domain at Teachable through your own Cloudflare account and switching on bot rules there. Teachable documents custom domains through a DNS setup it controls, and it does not document running your own Cloudflare proxy in front of a school. If the setup breaks your SSL certificate or your checkout, you will be debugging a configuration Teachable support does not cover. Ask Teachable support before you try it, and do not treat it as a documented feature.
The split decision: block training, keep discovery
Most Teachable creators land in the same place once they see the options clearly: block the training crawlers, allow the search crawlers. Here is why that split works well for a course business.
Training is a one-way deal. When GPTBot or ClaudeBot reads your sales page, your words may end up inside a future model, and you get nothing back. There is no link, no citation, no visit. Refusing that is a reasonable business decision, and the providers built their crawler settings to allow it.
Search is the opposite. When OAI-SearchBot, Claude-SearchBot, or PerplexityBot reads your sales page, your school becomes eligible to appear in AI answers with a link back to you. That is free distribution to people who are already asking about your topic. For a course creator, that is the most valuable traffic there is, because the person asking is already looking for a course.
The mistake to avoid is blocking everything at once. A single Disallow: / under User-agent: * looks tidy, but it blocks Googlebot too, and it blocks every search crawler along with the training ones. If you ever get access to a real robots.txt file — on your own site, not on Teachable — name each bot and give it its own rule. The same care applies to the meta robots tag: a sitewide noindex on Teachable hides you from Google as well as from AI, so use it only if you truly want the whole school out of search.
One more tool is worth knowing about. An llms.txt file is a short, plain-text summary of your site written for AI systems, and it is becoming a common way to tell AI tools what your site offers and which pages matter. You cannot host one on your Teachable school, since you cannot upload files to its root, but you can publish one on your own marketing site. Our free llms.txt generator builds one in a minute, and it pairs well with the robots.txt setup in option 3.
How to verify what is actually happening
Bot rules are only useful if you check them, and the checks are different depending on where your content lives.
Check your school's robots.txt. Open your school's address with /robots.txt at the end. You will see Teachable's platform file, with the AI crawlers listed and only the admin, account, login, signup, password-reset, and search paths blocked. That confirms what this guide says: your public pages are open to AI crawlers, and you cannot change that file.
Check your own site's robots.txt the same way. If you followed option 3, open your marketing site's /robots.txt and confirm your training-bot rules are there. Then test a few real URLs against it with a robots.txt tester to catch syntax errors before the crawlers do.
Allow about a day for changes to take effect. OpenAI says its search systems take about 24 hours to adjust after a robots.txt change. Other providers describe a similar delay. Do not judge a change by checking an hour later.
Test with a real question. After a day or two, ask ChatGPT or Perplexity a question your sales page answers, and see whether your school is cited. If it is cited, the search crawlers can still reach you. If it is not, check whether you blocked a search crawler by mistake, or whether the page simply has not been crawled yet.
Know what you cannot see. Teachable does not give school owners server logs, so you cannot watch GPTBot's visits to your school the way you could on your own server. On your own marketing site, your hosting logs or Cloudflare analytics will show bot visits directly. That visibility gap is one more reason the strongest controls live on a site you own.
For the official rules behind the tags and files in this guide, see Google's robots.txt specification and its robots meta tag documentation — both spell out exactly which directives crawlers are expected to honour.
Frequently asked questions
Can I edit robots.txt on Teachable?
No. Teachable manages the robots.txt file for every school, and it does not document any setting that lets a school owner edit it or add per-crawler rules. The file names the major AI crawlers but only blocks them from admin, account, login, signup, password-reset, and search paths. Your public pages stay open to them.
Can AI crawlers read my paid course lessons?
No, not through the normal front door. Lessons require a student login and an enrollment, and crawlers cannot log in. Your video lessons, worksheets, and lesson text sit behind that wall. The pages crawlers can read are your public ones: the school homepage, course sales pages, and any free previews you publish.
Does blocking GPTBot remove my school from ChatGPT?
No. GPTBot only collects content for training. ChatGPT search uses a different crawler, OAI-SearchBot, and ChatGPT-User fetches pages when a person asks about them. OpenAI says these settings are independent, so you can block GPTBot and stay visible in ChatGPT search. Just be careful not to block OAI-SearchBot by accident.
Can I use Cloudflare to block AI bots on my Teachable school?
Not directly. Teachable's school domains run through Cloudflare's network, but that setup belongs to Teachable, and Teachable does not document a way for school owners to add their own Cloudflare rules to a school. You can use Cloudflare's bot controls on a site you own, such as your own marketing site, but not on the school itself.
Should I add a noindex tag to my whole school?
Only if you want the school fully private. A noindex tag added through Code Snippets applies to every page in the school, so it removes your sales pages from Google as well as from AI crawlers. For most creators that is too much. If you want search traffic, leave the tag out and control access through enrollment and the login wall instead.
What is the best setup for a course creator who wants both protection and discovery?
Keep Teachable for courses and put your public content on a site you control. On your own site, block the training crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended) in robots.txt and allow the search crawlers (OAI-SearchBot, Claude-SearchBot, PerplexityBot). Your lessons stay behind Teachable's login, your blog and sales pages stay visible in search and AI answers, and you finally have a robots.txt file you can edit. For the same approach on other hosted platforms, see our guides on blocking AI crawlers on WordPress and blocking AI crawlers on membership and paywalled sites.
The bottom line
Blocking AI crawlers on Teachable is less about robots.txt and more about understanding where your content actually lives. Your lessons are already safe behind the login. Your public sales pages are open, and Teachable gives you no robots.txt editor to change that. A sitewide noindex tag is the only built-in lever, and it costs you Google visibility, so it fits only a fully private school. For everyone else, the practical answer is to let Teachable host the courses and put your public content on a site you control, where you can write the bot rules yourself, block training crawlers, and keep the search crawlers that send you students. That split — training out, discovery in — is the policy most course creators actually want, and it is the one Teachable's limits point you toward.
