Most content teams already have a pile of topic suggestions and still miss the actual problem a buyer is trying to solve. The suggestions came from a keyword tool or a brainstorm, not from watching what real searches surface. If you want to mine SERPs for content ideas that hold up, the move is to read several results pages closely, note the patterns across them, and follow the ones that lead to real public conversations. This guide walks through that process step by step, from choosing which searches to run to turning what you find into an assignment your team can actually write.
What you need: a browser, a spreadsheet or notes doc, a defined buyer and problem area, and access to Google search. You don't need a paid SEO platform to do this well. A repeatable worksheet matters more than the tool.
Set the buyer situation and the searches you'll run
Before you open a browser tab, decide who you're researching and what problem they're in the middle of. Don't start with a product category term like "content marketing software," because that mostly returns what vendors call the problem, not what a buyer types when they're stuck. Instead, pick a small set of searches that come at the same problem from different angles: a task someone is trying to do, a frustration they're having, a comparison they're weighing, and a concern about actually implementing something.
Say you cover content operations. Your search set might include something about keeping publishing output steady, something about keeping writing on-brand across freelancers, something about the time internal linking takes, and something about checking whether your content shows up in AI answers. Four to six searches spanning a problem is usually enough for one pass. You're not building a keyword list from every question that pops up. You're sampling a problem from several angles so you can see what recurs.
Write down the exact search you typed, the date, your country or region, language, and device. Keep those settings the same for the whole pass, because Google's own documentation says results can differ by location, language, and device, and you want to compare like with like rather than mixing conditions without realizing it. If your business genuinely serves more than one region or device audience, treat that as a second, separate pass rather than folding both sets of results into one table without labeling which is which.
Done when: someone else on your team could run the same searches and understand why you picked them.
Where people go wrong: searching only the head term or the product category. That gets you vendor language, not the words a buyer actually uses when they're looking for help.
Record what's actually on each results page
For every search in your set, look at the whole page before you click anything. Note whether a People Also Ask box shows up, whether related searches appear at the bottom, whether you see a labeled Discussions and Forums section, whether review sites are in the mix, and what other kinds of results are there. Write down the source domains, the thread titles, the visible questions, and the snippet wording exactly as they appear.
If a feature isn't there for a given search, mark it "not observed." Don't borrow it from a different search in your set just because it feels like it should be there. A screenshot or a dated note is worth keeping if you'll need to show someone else what you actually saw.
A simple worksheet works fine here. Columns for the search, the buyer situation it represents, the date, region, language, device, the PAA wording you saw, the related searches, any forum or review source, the result title, the snippet, your observation, and a separate column for your interpretation. Keeping observation and interpretation in separate columns is what makes this whole exercise defensible later. If you spot a genuine customer quote in a thread, give it its own field with the source location, since that's a different kind of evidence from anything else on the page.
Common mistake: treating a ranked result as proof that Google measured demand for that topic, or treating a snippet written by a publisher's marketing team as if it were a customer's own words. It isn't. It's copy someone wrote to get a click.
Read People Also Ask and related searches as patterns, not a task list
This is where most teams go wrong with SERP insights for content, so it's worth being deliberate. Across your sampled searches, look for the kinds of questions and refinements that keep showing up: definitions people need, setup problems, trade-offs, cost questions, alternatives they're weighing, failure cases, or the kind of proof they want before deciding. Write the exact wording in your observation field, and put what you think it actually means in a separate interpretation field.
Related searches are useful for a different reason. They show you how a topic branches into other situations or other words for the same thing. If a related search looks like it has nothing to do with the buyer you defined, mark it irrelevant and move on rather than stretching it into an article idea it doesn't support.
People Also Ask content ideas can look like a ready-made outline, and that's exactly the trap. Google generates that box automatically, and it isn't a transcript of interviews with your buyers. Copying a PAA question straight into an article title without checking who's actually asking it, or whether your answer fits that person, is how you end up with content that technically answers a question nobody in your audience has. This step is also where a lot of teams try to turn every PAA question into its own keyword target. That's a different job, the one where you build and prioritize a searched-question backlog. Here, you're just reading for the theme underneath the questions.
Done when: you can state a recurring concern in plain language and point to the specific searches where it showed up.
Notice where forums and review sites show up
Now look across your search set for where community and review sources enter the picture. Mark which forums, Q&A sites, and review sites appear, and whether they show up as ordinary results or inside a labeled discussion feature. Pay attention to what kind of question brought each one forward: someone asking for a personal experience, someone troubleshooting, someone comparing options, or someone trying to evaluate a purchase.
For a B2B software topic, that often means practitioner forums like Reddit or industry Slack communities that got indexed, plus software review sites. Record what you actually saw ranking, not what you assume should be there because a competitor told you it ranks.
This is also where SERP insights for content start to separate from generic keyword data. A keyword tool tells you a term gets searched. Watching which forums and review sites actually surface for it tells you where the people asking that question are already having the conversation, which is a different and more useful signal for deciding where to go looking for real language.
Done when: you can point to which searches surface first-hand discussion and which ones are dominated by other kinds of sources entirely.
Where people go wrong: assuming a forum thread is authoritative just because it ranks, or treating a review site's search result the same as the little star rating Google sometimes shows next to a listing. Those are two different things. One is a page linking to a discussion; the other is a rich result built from review markup on the page.
Check the actual words at the source
This is the one step where you have to leave the results page and read the actual thread or review. When a forum or review source ranks for one of your searches, open it and look for wording you can attribute to a real person: a question, a complaint, an outcome, an objection, a comparison. Copy a short, exact phrase, note whether it was a question or a complaint or something else, note the source and the date if you can find it, and keep enough surrounding context that you don't accidentally change what they meant.
If you can't verify a quote, write "no verified quote" and move on. Don't invent something plausible-sounding to fill the gap, and don't build a claim on a single angry review as if it represented the typical customer. A PAA label, a related search, a headline, or a Google snippet is never a customer quote, no matter how close it reads to one. "Customers say" requires an actual, attributable statement from an actual person. "The results suggest people may be concerned about" is the honest way to describe a pattern you inferred from the search page itself.
Done when: a colleague could go find the exact phrase in the public source and tell your summary apart from the person's actual words.
Group repeated concerns into content angles
Once you've got a set of observations, group them by the underlying problem they describe rather than by matching exact wording. Two different phrasings often point to the same difficulty, and what looks like one theme sometimes turns out to be two separate buyer jobs tangled together. Work through each group and check both directions before you settle on a theme.
For every angle you're considering, write down what you saw, what you think it means, which searches it showed up in, whether you have a verified quote backing it, an alternative read of the same evidence, and what you'd still need to check before you trust it. Call the need an inference until you've validated it some other way. A thin, provisional idea should stay provisional. Don't dress it up as a proven demand signal because you're excited about it.
Once an angle has some shape, check it against what you've already published. DeepSmith's Content Map crawls your site and your competitors' sites into one shared topic taxonomy, so you can see your coverage gaps and untapped topics against that map before proposing something that already exists somewhere in your back catalog. It's a check on your own coverage, not a tool that scrapes Google's PAA box or extracts forum quotes for you. The manual reading you just did stays manual.
Done when: an editor could trace your proposed idea back to specific observations and see clearly which parts are interpretation.
Pro tip: keep a running log of angles you rejected at this stage and why. A theme that looked thin from one search set sometimes turns out to be real once you run a second pass a month later, and you'll want the earlier notes instead of starting over.
Turn an evidenced angle into an assignment
Pick the angle your team can actually answer well, and write it up as a real assignment: the buyer's situation, the central question, the distinction the piece needs to clarify, what evidence or product detail it needs to back it up, and what's still unverified. Keep the source wording you gathered on hand for editorial judgment, but that doesn't mean every private person's words belong in your marketing copy. Route it through your normal editorial review, since reading a few search pages tells you nothing about expected traffic or business impact on its own.
This is also where the idea moves out of your research doc and into production. In DeepSmith, that means adding the evidenced angle to New Ideas and then scheduling it into Planned Content, where the writer pulls on your Deep IQ brand, product, persona, and voice context to draft it. The human judgment about what the public conversations actually prove stays with your editor. DeepSmith doesn't capture your SERP worksheet on its own or verify that a forum poster is a real buyer; it picks up the idea once you've done that work.
Done when: a writer can produce something useful without inventing a quote, a case study, or a result to fill a gap in the evidence.
Where people go wrong: stretching a loose thematic cluster into a firm claim about your whole buyer persona, or greenlighting a piece just because a forum thread happened to rank that week.
Recheck the idea against real customer evidence
Keep your original SERP notes and go back to them if the topic or the market shifts. Compare what you inferred against what sales is actually hearing, what customer interviews turn up, what support tickets say, and what later searches show. Note whether that evidence supports, narrows, or contradicts what you thought you saw.
Treat your AI-search visibility as a separate question from this. Ranking well in a conventional Google results page, or having a forum thread show up in your search set, doesn't tell you whether a page gets pulled into ChatGPT, Perplexity, or Google's AI Overviews. Google's own documentation says AI Overviews and AI Mode can search across related subtopics and show a different set of supporting links each time, and an overview may not show up at all. DeepSmith's AI Visibility tracks the specific buyer prompts you define and reports mentions, citations, and which pages get cited on the engines your plan covers, but that's a separate, ongoing measurement from the one-time SERP reading you just did. One doesn't convert into the other automatically.
Done when: your team can say plainly what you saw in search, what you later learned from actual customers, and whether the piece you wrote answered the right question.
Keep the evidence sheet with every idea you propose this way. The next useful move after a pass like this is to check the strongest inferred concern against actual customers, confirm it doesn't duplicate something you've already covered, and hand it to your team as an assignment they can defend. If your team is stretched thin turning validated angles into drafts, DeepSmith's free trial gives you seven days to move an evidenced idea through research, writing, and linking without adding that to your own plate.
