To get a whole WordPress blog into Claude or GPT, give the model clean Markdown rather than a live URL. Export each post as plain headings and words with the theme markup, scripts, and styling removed, keep one file per post, and upload those files. Two problems make the obvious approach fail: a live WordPress page hides its text inside theme code, and a blog of any size quickly outgrows what a single chat can hold. A per-post Markdown set solves both, and it is the format these models read most accurately. WPBuildAI generates exactly that export, a clean copy of every post, as part of a migration, so the blog is ready to feed to a model without the usual cleanup.
Why pasting a URL or raw HTML falls apart
A WordPress page is mostly not content. The words you care about sit inside theme containers, widget output, inline scripts, and stylesheets, and the model has to wade through all of it. The 2024 Web Almanac measured how heavy a typical page has become, with hundreds of kilobytes of markup and script arriving before the real text, and that weight does two things to a model: it eats the context window and it buries the content. The result is a truncated or muddled answer that looks plausible but misses half the post.
Google describes the same difficulty from the crawler’s side in its JavaScript SEO basics: pages that depend on scripts to render are harder for an automated reader to capture cleanly. A chat model fetching your URL hits that wall too. Strip the page to Markdown and the model sees only the headings, sentences, and links, which is what it can reason over.
The token cost is the part people underestimate. A post that is a thousand words of actual writing can ship as many times that in markup once the navigation, sidebar, footer, cookie notice, and inline styles are counted. Every one of those tokens competes with your real content for room in the context window, so a model fed raw HTML spends most of its attention on a menu it does not need and runs out of space before it reaches the end of the post. The same thousand words as Markdown is a fraction of the size, which is why a clean export lets you fit several posts where one raw page barely fit before.
Export each post as one clean Markdown file
The reliable unit is one Markdown file per post. Each file holds the title, headings, body text, and links, and nothing else, so it stays small and self-contained. That structure matters for accuracy as well as size. Research on what generative engines work with, the Generative Engine Optimization study from Princeton and Georgia Tech, found that clearly structured, well-labelled content is selected and quoted far more reliably than loose prose, and a clean per-post file is exactly that kind of input.
There is a recognised convention behind this clean, machine-readable form. The llms.txt standard points models at the plain-text version of a site precisely because stripped Markdown is what they parse best. Producing a per-post export is the same idea applied to a whole blog at once.
How to do it, step by step
- Export the posts with their text, headings, and links intact, dropping the HTML, scripts, and CSS.
- Save one Markdown file per post, named so you can tell them apart, with the original URL noted at the top.
- Upload in batches that fit the model’s context window rather than one giant block.
- Keep the per-post structure if you are building a knowledge base, so the model can cite the right post when it answers.
Noting the original URL inside each file pays off later: it lets the model attribute an answer to a specific post, and it is the same list you will need if you ever redirect those URLs.
What to leave out matters as much as what to keep. Drop the author box, related-posts widgets, comment threads, share buttons, and any repeated calls to action, because they appear on every post and add nothing the model needs. Keep the things that carry meaning: the headings, the body, the in-text links, and a one-line note of the publish date if recency is relevant to your questions. A file that is just the post, with its structure intact, is both smaller and clearer than the page a visitor sees.
A worked example: a 60-post blog into Claude
Picture a blog with sixty posts averaging around twelve hundred words. Pasting URLs one by one is slow and some fetches will quietly return half a page. Pasting the rendered HTML fills the context window with repeated theme markup, so after a handful of posts there is no room left. The export approach handles it cleanly: sixty Markdown files, each a few kilobytes, grouped into two or three uploads that sit comfortably inside the context window.
From there the workflow is predictable. You upload the first batch, ask the model to confirm how many posts it can see, then ask your questions across them. For a knowledge base you keep all sixty files together so the model can pull the one post that answers a query and name it. When a blog is larger than the window even as Markdown, you summarise each post into a short structured note and keep the full files in reserve for when a question needs the detail. None of this works reliably with raw pages, which is the whole reason to export first.
Which format suits which job
The right export shape depends on what you are feeding and why. The differences are easiest to see side by side.
| Goal | Best input | Why |
|---|---|---|
| Ask questions across the whole blog | Per-post Markdown files | Each post stays a distinct, citable chunk the model can retrieve |
| Summarise or rewrite one post | That post’s Markdown, pasted or uploaded | No fetch to fail, no theme markup to confuse the model |
| Build a custom GPT or knowledge base | Per-post Markdown set, URLs noted | Clean chunks improve retrieval and let the bot cite the source |
| Archive the blog as one document | A single concatenated Markdown file | Convenient snapshot, though too large to reason over in one pass for big blogs |
A single bundled file is fine for archiving a small blog, but for retrieval and accuracy the per-post set wins, because the model can pull the one post that answers a question instead of searching a wall of text.
Before you upload: a short checklist
A few minutes of preparation saves a lot of confused output:
- Confirm each file is clean Markdown, not exported HTML with the tags still in it.
- Check that images are referenced sensibly or noted, since a model reads alt text and captions, not the image itself.
- Keep the original URL at the top of each file for attribution.
- Decide your batch size from the model’s context window rather than uploading everything and hoping.
Will the model remember the blog next time?
A plain upload lasts only as long as the conversation. Start a new chat and the files are gone, because a normal session does not retain what you uploaded. That surprises people who expect a one-time upload to teach the model their blog permanently. If you need the content to persist, two options fit. A custom GPT or a project with attached files keeps the Markdown available across conversations, so the same per-post set you would upload to a chat becomes its standing knowledge. A retrieval setup goes further, indexing the files so the model pulls only the relevant post for each question rather than holding the whole blog in context.
Either way the input is the same clean per-post Markdown, which is why the export is worth doing once and reusing. The difference between a throwaway chat and a lasting assistant is where you put the files, not how you prepare them, so prepare them well and you can use them in both.
Keeping the export current after edits
A blog changes, and an export is a snapshot. If you edit posts often, treat the Markdown set as something you regenerate rather than build once, so the model is not answering from last quarter’s copy. Re-export the posts that changed, replace those files, and re-upload or re-index. Because each post is its own file, you swap only what moved instead of rebuilding the whole set, which keeps the maintenance small. Noting the publish or update date inside each file makes it obvious which version the model is working from. If you publish weekly, a quick re-export of the past week’s posts is usually all it takes to keep the set trustworthy, and it takes minutes rather than a full rebuild.
When uploading is not the right approach
Uploading files is the dependable method, though it does not suit every job. If you only need an answer about one or two posts, pasting the cleaned text into the chat is faster than exporting the whole blog. If you want the blog to stay continuously in sync with a live tool, a file upload is a snapshot, not a connection, and you would look at an API-fed setup instead. And if the blog is genuinely large, no single upload will hold it, so plan for batches or per-post summaries from the start rather than expecting one paste to work.
Why a URL fetch can look like it worked when it did not
The quiet failure mode is worth naming, because it costs people trust in the model when the fault is the page. When you give a model a URL and it returns a confident summary, it is summarising whatever it managed to fetch, even if that was a half-rendered page or mostly navigation. It does not announce that the capture was incomplete, so you get a tidy answer built on a fraction of the post. Across a whole blog, a few of those partial fetches are easy to miss, and they show up later as answers that contradict what the post actually says. A clean upload removes the guesswork: the model is working from the full text because you handed it the full text, so when it is wrong you can see that the content, not the capture, is the cause.
The export is also a migration head start
The same clean, per-post export that an AI reads well is the inventory a clean migration runs on, which is why moving a blog and making it AI-ready are really one job. Rebuild from the exported content, keep the slugs so the URLs barely change, and map anything that does change to a 301 redirect, and the blog moves to a faster platform without losing the rankings it has earned. The mechanics of that move are covered in moving WordPress blog posts without losing rankings, and the site-wide version of the export in turning your whole website into ChatGPT-ready Markdown. If you would rather not export and clean hundreds of posts by hand, WPBuildAI produces the per-post Markdown set and the redirect map together; send your site URL for a fixed quote.
Key points to remember
Claude and GPT read clean Markdown, not WordPress HTML, so the reliable way to upload a whole blog is to export stripped Markdown files, one per post, and feed them in batches rather than pasting a URL. Note each post’s URL for attribution, match your batch size to the context window, and keep the per-post structure for any knowledge base. The same export doubles as the starting point for a clean migration, since a clean copy of every post is what both a model and a platform move need.
Not affiliated with OpenAI, Anthropic, or WordPress.