When you read a web page, you know straight away what you are looking at. You see a headline, a name and a date below it, and further down a row of questions with answers. Without thinking about it you know: this is an article somebody wrote, and at the bottom there is a question-and-answer part.
A computer program does not know that. It gets the same text, but without your background knowledge. To a program a headline is first of all just a line displayed in a larger size. Whether it holds the title of an article or the name of an advertisement does not follow from the size.
For search engines and for systems like ChatGPT this is not an insurmountable obstacle. The visible text already carries plenty of information, and these systems do evaluate it. Structured data adds machine-readable details on top and makes certain relationships explicit: that this line is the headline of an article, that this person wrote it, that six questions with their matching answers sit further down.
What structured data is
There is an established method for these extra details, and it is older than the AI systems. Put simply, structured data is a machine-readable information sheet for a web page: it does not appear on the page itself but sits in its source code, and it describes in a fixed form what the visitor sees.
Two terms belong here, and they do not mean the same thing. Schema.org is the vocabulary used to describe content and its properties — it defines that there is a type called Article and that it can carry a headline, an author and a datePublished. JSON-LD is one of the technical formats in which those details are embedded into a page; it sits as its own block in the source code. So the vocabulary says what is described, the format says how it gets in there.
Such a block says, for instance: this is an article. Its headline reads as follows. This person wrote it, and it was published on this day. And further down: six questions follow here, and these are the matching answers.
On many pages this is missing. They are well written and have been online for years, but the source code says nothing about it. Ten questions with answers sit at the bottom, and none of it is explicitly marked as such.
One thing should not be expected of it: structured data is not an automatic ranking factor and guarantees no better position in the results. It can help search engines classify content and relationships, and for some data types it enables additional presentations in the results.
Why the page does not have to be rewritten
The obvious thought would be to write the piece again in the Content Studio and get everything right this time. That is a lot of work for a small goal, since the text itself is fine.
There is an easier way. You give the address of the existing page and the studio fetches it. The content appears in the editor, you can edit it there, and when you save, the structured data that was missing is built.
What happens when the page is fetched
A web page is not only text. Its source code also holds instructions on how it should look, and small programs that run in the visitor's browser. A menu belongs to it, a footer, often advertising as well.
Only the content of all that reaches the editor: headings, paragraphs, lists, tables, images and links. Everything else is removed beforehand.
That is not a convenience but a question of safety. The editor takes over the editorial content of a foreign page, not its executable part. If a program came along, it would run in your browser, and you would have no way of checking what it does.
The sequence therefore looks like this: the page's HTML is read in, the editorial elements are lifted out, scripts and styles stay behind, and what remains can be worked on in the editor.
There is one exception, and it has a reason. If the page holds a quiz, meaning questions you click on, its logic does not sit in the visible text but in invisible extra details: which of the three answers is the correct one, which options belong to which question, which explanation appears after the click. Remove those details along with the rest, and all that remains of the quiz is a list of unconnected sentences. They are therefore taken over — but only they. Anything that could start a program falls away here too.
Why existing markup is not carried over
Some pages already bring markup with them. You might assume the studio simply takes it over. It does not, and the reason matters more than it first sounds.
Existing markup describes one particular state of the page. The moment you change something in the editor, that description no longer holds. You drop a question, and the markup keeps claiming there are ten. You rephrase the headline, and it still names the old one.
A description that says something other than the page is worse than none at all. If structured data does not match the visible content, it can become unusable for search presentations; where the guidelines are breached, Google may also take manual action.
The studio therefore only reads the existing markup and files it as a finding. The finding tells you what sits on the source page: how many blocks there are, which types appear in them, which questions are marked up, who is named as author. That is useful to know — but it does not travel into your draft.
So the Content Studio does not adopt existing markup. It evaluates the current content of the page and builds a matching structured description from it. That way the markup describes the state the edited piece actually has, and not a possibly outdated state of the original web page.
The sequence from end to end: read in the existing page, evaluate the content, check the existing markup as a finding, edit the content in the editor, build the structured data afresh, output it as an HTML file or to WordPress.
What is built when you save
The moment you save, the studio looks at your text and assembles the structured data itself. Three parts can come out of it.
The first is the frame for the article. It names the headline, a short description, the author and the publisher, the preview image, the date of publication and of the last change, the language and the length of the text. All of these already exist somewhere — they are simply collected.
The second part is the question-and-answer section. If your text carries a heading such as „Frequently asked", the questions below it are read and marked up as such. Only those below it, mind: some articles also run their chapters as questions, and those do not count. Anyone looking under that heading expects a particular handful, and the markup should reflect what the page promises.
Two things are worth knowing about the question-and-answer part. First, FAQPage markup describes the questions and answers in machine-readable form, but it does not necessarily lead to an enhanced presentation in Google's results: Google shows those today only for certain particularly authoritative websites. The markup remains worthwhile nonetheless, because it labels questions and answers explicitly as such and supplies additional machine-readable information — including for systems beyond classic search.
Second, there are two related types that are easily confused. FAQPage stands for editorially written questions and answers, of the kind an editorial team puts beneath an article. QAPage describes a page where users themselves ask questions and submit answers, meaning a forum. For editorial content FAQPage is the right type, and it is the only one the studio builds.
The third part is the quiz, if one sits in the text. The question, the correct answer and the explanation are taken over.
The three parts are combined into one, with the article at the top. If you have worked on a part yourself, it stays untouched — only what is missing gets added. A second save therefore changes nothing.
You pay nothing for this. No language model is involved, nothing is estimated and nothing predicted. The text is read, and what stands in it is entered.
What does not happen
Nothing is invented. If a detail is missing, the field stays empty rather than being filled with a placeholder. There is no substitute image, no made-up author and no estimated date. A gap is more honest than a value nobody checked.
Also left out is anything that looks like a question but is not. At the foot of many pages sits an invitation in question form, something like „Ready to get started?", with a button underneath. Formally that is a question-and-answer pair; in substance it is advertising. It has no place in a question-and-answer section, and Google explicitly excludes promotional content there.
How the finished piece comes back out
Two routes lead out of the editor, and both carry the same markup.
One writes an HTML file for you to download. At the top sits the invisible part with title, description, author and the JSON-LD block, the text below it. That file drops into any system.
The other route pushes the piece, markup included, straight into a WordPress installation.
Both check beforehand whether what they are handing over is markup at all. Until September 2026 the download carried the finding about the source page — that is, the note about what had been found on the foreign page. Technically that note is well formed, but it describes nothing that has anything to do with your piece, and it sat in the source code without the wrapper it needs. Ten kilobytes of diagnosis between the details about the piece. Today both routes run through the same check, and anything that is not valid JSON-LD is not emitted.
Where the limits are
What gets fetched is the content, not the appearance. Fonts, colours and the source page's own building blocks stay behind. That is intended, because in the editor you work on the text and not on the design.
Some pages assemble their content in the visitor's browser while they are being viewed. From such pages, only what was already fixed beforehand arrives.
And the markup can only describe what is actually there. Where no question sits in the text, no question-and-answer section appears. Anyone who wants one has to write questions — the studio enters what it finds and adds nothing of its own.
When this route is worth it
It is worth it for a page that is fine in substance and only lacks the description. It is worth it for an older piece you meant to revise anyway. And it is worth it when you want to find out, across several pages, whether any markup exists at all — the finding alone answers that, without you changing anything.
It is not worth it when a piece needs rewriting anyway. Then you are better off starting from a brief than rescuing the old text.
Frequently asked
Can I fetch any page?
Any page that stands publicly on the web, including other people's. What does not work are addresses from internal networks and pages that only appear after a login. The fetch behaves like an ordinary visitor and takes what the page shows it.
Am I changing the original page?
No. It is only read, the way a visitor reads it. What is built in the studio belongs to your draft and leaves it only when you download the file or publish the piece.
What does it cost?
Nothing. The article frame, the question-and-answer section and the quiz come purely from your text, without a language model doing any work. Credits are only charged for the other variant, where an AI drafts a proposal — you do not need it for this route.
Why does my question-and-answer section hold fewer questions than the text?
Because only the questions below the heading „Frequently asked" are taken. If your piece also runs its chapters as questions, those stay out. If such a heading is missing altogether, the whole text is evaluated instead.
Can I still change the structured data afterwards?
Yes. It sits visibly in the editor and can be copied or edited by hand. What you have changed survives the next save, because only what is missing gets added.
What becomes of a quiz from the source page?
The structure is taken over, the accompanying program is not. On download and on publication the studio adds one of its own. That way no foreign program code reaches the editor, and the quiz still works.