Ali Demirci, Woofocus. September 2026.
A keyword tool tells you what a market types into Google. Your support inbox tells you what your own customers could not work out on their own, in the words they used when they gave up and asked a human.
Those are not the same list. The second one is shorter, less glamorous, and far more likely to turn into a page that earns its place.
This is what people mean by voice of customer SEO: building content from the language your customers actually use rather than from a tool’s suggestion list. Most guides on it stop at sales calls. Sales calls are useful, but they are recorded before anyone has used the product. The support inbox records what happened after. That is the part almost nobody mines, and it is usually sitting in a help desk that nobody has ever exported.
This page is the method we use, including the parts where it does not work.
What voice of customer SEO actually is
Take the questions your customers ask you directly, in writing, and let them decide what you publish. Keyword tools then get used the way they are good: to check demand and to find the phrasing that a wider audience uses for the same question.
The order matters. Tool first means you write what a database thinks a market wants. Customer first means you write what you have watched people struggle with, then check whether anyone else is searching for it.
Google’s own guidance for creating helpful content asks whether your content “clearly demonstrate[s] first-hand expertise and a depth of knowledge,” and whether a reader will “leave feeling like they’ve had a satisfying experience” rather than needing to search again. A page written from a real support thread starts with an advantage on both counts. You already know what the unsatisfying answers were, because you watched the customer come back.
Why the support inbox beats the sales call
Sales calls are full of objections and budget talk. Useful for landing pages, thin for everything else.
Support tickets have four properties that make them better raw material:
They are written, not remembered. No transcription, no paraphrase. The customer’s own sentence is sitting there.
They are post-purchase. The person has the product, the plugin, the account. They are describing reality, not a hypothetical need.
They repeat, and repetition is countable. One ticket is a reply. The same question five times is a page. You do not need a tool to tell you the volume, you have your own.
They come with a cost attached. Every recurring question is support time. A page that removes it pays for itself whether or not it ever ranks, which makes this the rare content work you can justify before it performs.
From our logs. We are in the middle of this with a B2B software company we look after. We asked for their support tickets, and specifically asked for them with the conversations attached, not the subject lines and resolution codes. The subject line is the agent’s summary of the problem. The conversation is the customer’s description of it, which is the part that matters. Their customer experience manager is having a custom report built for us. Most help desks will not give you this in an export by default, so ask for it explicitly.
The method
1. Export tickets with the conversation body
Subject lines alone will mislead you. Agents normalise language as they type: “login issue” is not what the customer wrote, and “login issue” is not what anyone searches. Get the thread.
Twelve months is plenty. If the product changed significantly in that period, cut the window to the period since.
2. Strip the account, keep the question
Remove names, URLs, order numbers, licence keys, anything account specific. What is left is a question and the words it was asked in. This step is not optional: the output of this process ends up on a public web page, and customer support data is not yours to republish.
3. Group by the question, not by the ticket
You are looking for the same problem described five different ways. This is where AI is genuinely useful and where it is genuinely risky. It is good at finding the twentieth instance of a pattern a person has already spotted, and poor at deciding what matters. Cluster with it, then read the clusters yourself. We use the same rule here as everywhere else: a person checks every finding against the source. How we test websites with AI sets out where we draw that line.
4. Sort the clusters into three piles
Fix the product. Some recurring questions are not content problems. If ten people cannot find the download link, write a better link, not a blog post. Publishing a page about a broken interface is how you end up with content that ranks for your own failure.
Write the page. The question is real, the answer is stable, and a link would have replaced the reply.
Answer once, privately. One customer, one edge case, one email. Not everything deserves a URL.
5. Now open the keyword tool
Take the phrasing from the tickets and check it. Three outcomes:
- Volume exists and matches the phrasing. Easy. Write it.
- Volume exists under different words. The market says “shipping zones,” your customers say “postcode rules.” Use the market’s words in the title and the customer’s words in the body. Both audiences find it.
- No measurable volume at all. This is the interesting case. If the question costs you real support time, publish anyway and accept the page will not bring traffic. It will deflect tickets, and it gives support a link to send. Judge it on that.
6. Write it so the reply can be replaced by the link
This is the whole test. Send the page to whoever answers the tickets and ask: next time this arrives, can you reply with just this link? If they say “yes, but I’d add”, add that and ask again.
A page that passes this test is also the page that answers the search query properly, because the same person asked both.
7. Measure two things
Ticket volume for that question, and impressions for the page. A page can fail the second and still be worth keeping on the first.
From our logs. One of our own maintenance checklist items predates all of this: every month, that month’s support emails get turned into test cases, so the thing a client reported once gets checked forever after. The inbox was already treated as a source of truth about what breaks. Reading it a second way, as a source of truth about what confuses, costs very little extra. The monthly checks are listed in our SEO audit checklist, and on maintenance retainers they run on a written schedule.
Our own inbox, as an example
We are an agency, so our support inbox is full of clients asking us about their own websites. The pattern holds.
A UK recruitment client asked whether candidates could be stopped from typing their names in capitals on application forms. We shipped the fix. It is also a page: no keyword tool would ever suggest it, and any organisation taking applications through a web form has the same data quality problem sitting in its ATS.
A store client asked how their shop page would behave through a domain change. That is two of our pages colliding, WooCommerce SEO and migration, and the question arrived in the words a store owner would actually use.
The pattern goes further back than that. Parts of our WordPress security writing exist because the same errors kept arriving in the inbox from unrelated clients on unrelated hosts, which is the clearest signal there is that a problem is general rather than local. A nonce verification error does not look like a content opportunity when it lands in a ticket. It looks like a Tuesday.
Where this does not work
Three honest limits.
Your inbox is not your market. It contains customers, not prospects. Support-led content ranks for problem queries, which sit late in the journey and convert well but are capped by however many people have the problem. It will not tell you what someone searches before they have heard of you. You still need demand research for that.
It over-represents whatever is currently broken. A bad release will flood the inbox for a month and skew the whole exercise. Look at twelve months, not the last thirty days, and discount anything that maps to a bug you have since fixed.
Search data undervalues the same pages twice. Some of what customers need most is reached from an email or a PDF, never from Google, so it looks unimportant in every report you own. We lost a form in a rebuild for exactly this reason: it was not indexed, its traffic came almost entirely from links sent directly to clients, and in search data it read as a page nobody wanted. That story is in our SEO audit checklist, and it applies here too. The inbox is the only place that page ever appears.
One more, on formatting rather than strategy. Support-led content invites an FAQ block, and FAQ blocks used to earn extra space in search results. They no longer do: Google stopped showing FAQ rich results on May 7, 2026. Keep FAQ markup where the page has a visible FAQ, because Google says it can stay, but do not structure a page as an FAQ expecting the rich result. More on that in schema markup.
Why this matters more in 2026 than it did in 2020
People no longer only type three words into a search box. They describe the problem in a sentence, to a search engine or to an assistant, and the phrasing they use is much closer to how they would write a support ticket than to how they would enter a keyword.
That is the practical case for this method now. The raw material you need to sound like the answer to a natural language question is already in your help desk, written by the people you want to reach, and your competitors are still exporting it to nowhere.
We are not going to put a number on that shift, because we have not measured one. What we can say is that the source material costs nothing and the customer wrote it for you.
Frequently asked questions
What is voice of customer SEO? Building content from the language customers actually use, taken from sources like support tickets, sales calls, reviews and emails, rather than starting from a keyword tool’s suggestion list. Keyword tools are still used, but to check demand and phrasing after the topic has been chosen.
Where do I get voice of customer data if I have no support tickets? Sales emails, onboarding calls, your site’s search box, review sites, the questions people ask in the communities where your customers already sit, and the replies your team types most often. Any repeated question written by a customer will do.
How many tickets do I need before this is worth doing? Enough that questions repeat, which for most small businesses means a few hundred tickets across a year. Below that you can still do it informally: ask whoever answers support which three questions they are tired of answering.
Is it safe to publish content based on customer support tickets? Only after stripping every identifying detail. Remove names, company names, URLs, account and order numbers, and never quote a customer directly without written permission. Publish the question, not the ticket. If a story is recognisable to the customer who lived it, it needs their approval or it needs changing.
Can AI do this for me? It can do the grouping, which is the tedious part. It should not do the deciding. AI will happily cluster ten tickets about a broken button into a content opportunity, when the correct output is a bug report.
Will these pages rank? Some will, some will not. Problem-phrased queries usually have lower volume and lower competition than the head terms in your niche, which makes them winnable and makes them convert. The pages that never rank still earn their place by deflecting the ticket, which is why we measure both.
Want a second pair of eyes on it?
If you have a help desk full of questions and no time to read it, that is a piece of work we do. We will also tell you which of the findings are content and which are things to fix on the site, which is usually the more valuable half.
Email info@woofocus.com with what your support team is tired of answering. Replies within one business day. It sits alongside our technical SEO work and our SEO audit.
Sources
- Google Search Central, Creating helpful, reliable, people-first content
- Google Search Central, FAQPage structured data