aiwebpageseo / SEO Tools / My Questions / Tutorial

My Questions Tutorial: Save Your Niche Research

This beginner tutorial shows how to use My Questions to build a saved research workflow — pick your seeds, run a refresh, read the report, and turn it into content you can publish.

🔎 Open My Questions Full Guide →

Step by step

1

Choose your seed keywords

Enter up to five keywords that describe your niche — for example "schema markup seo", "answer engine optimization", "local seo restaurants". Save your seeds so you can re-run them later with one click.

2

Run a refresh

Run the tool. It pulls live Google question data for your seeds along with answers from authoritative sources, and saves the run as a dated report automatically.

3

Read your report

Review the questions and their answers. The answers show what a good response covers — treat them as research, not copy to paste. Past reports stay in your list so you can come back any time.

4

Turn it into content

Build an FAQ page or post from a question cluster, writing your own answers. Export to CSV to plan an editorial calendar. The reports-to-content guide covers each route.

5

Re-run to track trends

Run the same seeds again in a few weeks and compare reports to spot newly trending questions in your niche — and publish before competitors catch on.

Beginner tip: keep your seeds focused. Five tightly related keywords give a sharper, more usable report than five unrelated ones that scatter the results.

Why the questions are the asset and the answers are not

Step 3 tells you to treat the generated answers as research rather than copy. That instruction is doing more work than it appears to, and it is worth understanding why.

An answer written from the same public sources everybody else used will say what everybody else says. Publish it and you have produced a page containing no information that was not already available, giving no reader a reason to link to it and no search engine a reason to prefer it. There is no penalty for that — there is no thin-content sanction in the technical sense — it is simply a worse answer than the pages it is competing with, and it ranks accordingly.

The questions are different. They are evidence: somebody typed that, wanted to know, and went somewhere to find out. That evidence is expensive to gather and is now sitting in your report. What you build on top of it is the part only you can do.

The test for every answer you write: what does this contain that the existing answers do not? A number from your own data. A test you actually ran. A limitation the competing pages avoid mentioning. An account of what went wrong when you did it. If the answer is "nothing", do not publish — and the discipline of not publishing is the most under-rated skill in content work.

The extraction test

There is one test that does more for a page than any amount of technical optimisation, and it takes ten seconds per answer.

Take the paragraph. Remove it from the page. Read it cold, as somebody who has never seen your site.

Does it answer the question completely, on its own, without depending on the heading above it or the sentence before it? If it does not, it is a fragment — and a fragment is useless to a reader skimming for the answer and useless to any retrieval system trying to quote you, because there is nothing quotable there.

This single test eliminates the most common failure in FAQ writing at a stroke: the answer that begins "As mentioned above…" or "This depends on your plan" and then stops. Both are pointers. Neither is an answer, and neither survives being lifted out of the page — which is exactly what a skimming buyer and a summarising assistant will both do with it.

Choosing what to write, and what to leave

A saved report will eventually hold forty questions, and the instinct is to sort by volume and work down the list. That produces a predictable outcome: generic answers to popular questions, competing against pages that answer them better, and a growing collection of thin pages that will one day have to be deleted.

Two better sorts, neither of which the tool can compute for you:

Then group honestly. If two questions would send a reader in different directions, they are two pages. If they would not, they are one, and the extra page is a cost with no benefit.

What the trend comparison in step 5 is actually good for

Re-running the same seeds and diffing the reports gives you one genuinely valuable signal: questions that were not there before.

A new question usually means something changed in the world — a platform shipped an update, a widely-read post got something wrong and a thousand people went looking for a correction, a rule came into force. Those are the moments where speed pays, because the existing coverage is thin and everybody is looking at once.

But hold the reflex in check. "Publish before competitors catch on" is only good advice if you have something to say. A fast post written from the same sources as everybody else's fast post is a thin page with a timestamp, and in a fortnight it is dead. A fast post reporting your own test of the thing that changed is the page everybody cites for the next two years.

The rest of the report — the stable, recurring questions that appear every time you re-run — is not a speed problem at all. That is stable demand, and stable demand rewards depth: the definitive answer, written once, properly, and kept current.

Keeping the seeds tight, and why it matters more than it sounds

The tip about keeping five seeds tightly related is doing real work, and the reason is worth spelling out.

Five unrelated seeds produce a report scattered across five topics, and a scattered report invites a scattered content plan — one page here, one page there, none of them reinforcing any other. Five tightly related seeds produce a dense map of a single subject, and a dense map lets you see the thing that actually matters: which questions cluster together, which are the same question wearing different words, and where the genuine gaps sit.

That density is also what lets you build a set of pages that support each other rather than compete. Several near-identical pages, each targeting a phrasing of the same question, will end up competing for the same query — Google will pick one and largely ignore the others, and the rest were written for nothing. There is no duplicate content penalty; consolidation is not punishment. But consolidation still means the extra pages were a cost with no return.

One question, one page, answered properly. A tight seed set is what makes that discipline visible; a scattered one hides it.

Marking it up, without expecting magic

Once the answers are written and visible on the page, mirror them into FAQPage schema. Then be clear about what that buys you, because the honest answer is narrower than the usual advice suggests.

It does not buy a rich result. Google restricted FAQ rich results to recognised government and health sites in 2023, and removed HowTo rich results entirely. A commercial page will not get FAQ dropdowns in the search listing however clean the markup is, and any guidance still promising that enhancement is describing a world that ended three years ago.

What the markup does is make the structure explicit in the served HTML: this string is a question, that string is its answer. A parser that would otherwise have to infer the relationship from your heading levels no longer has to. That is a clarity benefit, it is real, and it is the whole of it — there is no verified evidence that denser structured data wins citations from AI assistants.

Two rules follow and neither is negotiable. Every question and answer in the schema must appear, in the same words, in the visible text. And never invent a question to justify the markup: if nobody asked it, answering it publicly serves nobody, and marking up content the page does not contain is a policy violation rather than an optimisation.

Frequently asked questions

Why are search-derived questions better than brainstormed ones?

Because a brainstormed FAQ records what a marketing team believes its buyers wonder about, and it fails in a consistent direction: it answers the questions the business wishes people were asking. "How does our platform accelerate collaboration?" is not a question anybody has ever typed into anything. "Does it work offline?" is, and it is the one that decides a purchase. Questions taken from real search behaviour arrive without that flattery attached — frequently blunt, frequently about limitations, and frequently about the thing your positioning has been carefully steering around.

Can I publish the answers the tool returns?

The tool tells you not to, and it is right. Those answers exist to show what a complete answer covers — its shape, the points it must address, the caveats it cannot skip. Publish them and you have a page saying roughly what every other page on the subject says: no information that is not already available elsewhere, no reason for anybody to link to it, and precisely the kind of derivative content that gets reassessed downwards when Google runs a core update. The questions are the asset. The answers are the work.

What makes an answer worth publishing?

That it survives extraction. Take the paragraph, remove it from the page, and read it cold as somebody who has never seen your site: does it answer the question completely, without leaning on the heading above it or the sentence before it? If not, it is a fragment — useless to a reader skimming and useless to any system trying to quote you. Beyond that: be specific where others are vague, give the number, and say what the thing does not do. The sentence admitting a limitation is the one a sceptical reader believes.

How do I choose which questions to answer first?

Not by search volume, which is the obvious sort and a poor one. Volume tells you how many people ask; it says nothing about whether you can answer better than the pages already ranking, or whether the asker would ever buy from you. Sort instead by whether you have something true and specific to say that the existing answers do not contain. A low-volume question you can answer definitively is worth more than a high-volume one you can only answer generically — and answering the second generically is how sites accumulate the thin pages they later have to delete.

How many questions belong on one page?

As many as genuinely belong together, which is usually fewer than expected. A cluster is a set of questions somebody would ask in one sitting. A page that answers those properly is far more useful than a page listing thirty questions from four unrelated clusters, each dispatched in two sentences — the mega-FAQ, which is useful to nobody. If two questions would send a reader in different directions, they belong on different pages.

Should I add FAQPage schema to the page I build?

It is worth adding, and not for the reason usually given. FAQ rich results were restricted by Google to recognised government and health sites in 2023, so a commercial page will not get FAQ dropdowns in the search results however clean the markup. What the schema still does is make the question-and-answer structure explicit in the served HTML, so a parser does not have to infer which passage answers which question. Two rules: every question and answer in the schema must appear in the visible text, and never invent a question to justify the markup.

What does re-running the same seeds actually tell me?

Which questions are new, which is a narrower and more useful signal than it sounds. A question appearing that was not there six weeks ago usually means something changed in the world — a platform shipped an update, a widely-read article got something wrong, a regulation came into force. Those are the moments where a fast, specific, genuinely informed answer is worth publishing, because the existing coverage is thin and everybody is looking. The rest of the report is stable demand, and stable demand rewards depth rather than speed.

🔎 Start your saved research

Five seeds, real questions with answers, kept as reports. Pay as you go.

Open My Questions →

Next steps

About aiwebpageseo

aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.