Search Intent: Reading the Intent Behind a Query and Choosing the Right Content Format

Version note: The code in this post was built and run with .NET 10; the post is based on the 11 September 2025 version of Google's Search Quality Rater Guidelines and the state of the Search Central documentation in November 2026.

Guess First

Four developers type "ef core migration" into Google on the same day. The first is just learning EF Core and wonders what a migration is. The second added a property to their model and is looking for the command. The third is about to ship a wrong migration to production and is looking for a way to roll it back. The fourth is fighting an error from the dotnet ef command. The query is the same, but there are four different needs. The Bookstore blog has a single long guide for this query. Do you think that page can answer all four? Or does the query really belong to one of them?

What Is Search Intent? The Classic Classification

Search intent is the purpose behind a query: when readers type these words, what do they want to do, learn or reach? The most cited classification in SEO literature comes from Andrei Broder's 2002 paper "A Taxonomy of Web Search". Broder argued that web searches are not only about finding information and carry three main purposes: informational (learning about a topic), navigational (reaching a specific site) and transactional (doing something: downloading, buying and so on). The SEO industry often adds a fourth type: commercial investigation, comparing options before a decision. That fourth type is not in Broder's paper; it is a practical addition by the industry.

Google's Search Quality Rater Guidelines use a similar frame with different names. According to the guidelines, a query can carry a Know intent (learning about a topic), a Do intent (achieving a goal or doing something), a Website intent (reaching a specific site or page) or a Visit-in-person intent (going to a physical place). Know Simple, a special kind of Know, covers queries that want a precise answer most people would agree on and that fits in a sentence or two or a short list. The guidelines make two more important points: a query can have several intents at once, and the dominant interpretation of a query can change over time. Rater scores do not change rankings directly, but they are the clearest source for understanding Google's definition of a "good result".

Intents Specific to Developer Queries

A technical blog's queries fit these general classes, but a slightly finer split helps when deciding on content format:

The row most often overlooked is the error message. The reader arrives with a problem and has no patience; they leave a page whose answer sits in the middle of the third section and move on to the next result. The same reader is more willing to read a whole topic for an "X nedir" query.

Reading the SERP

The most reliable way to guess a query's intent is to look at what Google shows for it. The SERP carries Google's own interpretation of what users found helpful for that query. Things to look at:

The formats on the first page. Are most results official documentation (Microsoft Learn), step-by-step blog posts, Stack Overflow answers or videos? If forum answers and short posts dominate "ef core migration geri alma", the reader wants a quick and focused fix. If Microsoft Learn's overview page ranks first for "ef core migration", the dominant intent of the query is to learn the concept.

Features on the results page. A video box, "People also ask", an AI Overview or a featured snippet show which kind of answer Google finds helpful for this query.

Dates. If the top results were published or updated in the last few months, the query may want fresh information.

Do this by hand, in a private window and in the target language. Querying the results page in bulk with automated tools is not a solution: the machine-generated traffic section of Google's spam policies covers sending automated queries to Google Search without permission. Looking by hand at the five to ten most important queries of a family is usually enough.

AI Overviews and Clicks

When reading a SERP you now need to ask one more question: does this query show an AI Overview? According to Google's "AI features and your website" page, AI Overviews appear only when Google's systems consider them useful beyond classic results, and there are no additional requirements for your site to appear in these features. The same page says that users who click through from results pages with AI Overviews tend to spend more time on the site, and this traffic is counted in Search Console within the "Web" search type, without a separate row.

There is independent data on clicks as well. According to Pew Research Center's analysis published in July 2025, based on the March 2025 browsing data of 900 US adults, users clicked a classic result in 8% of visits to searches with an AI summary, compared with 15% for searches without one. Google disputed the finding, saying it does not reflect the full value delivered to publishers. The takeaway for content decisions: keep click expectations low for Know Simple queries whose answer is a single sentence; such queries can still be worth it for visibility. We covered how AI answer engines choose and cite sources in detail in the GEO series.

Queries That Want Freshness

A separate section of the rater guidelines covers queries that demand freshness: breaking news, recurring events and information whose value depends on being current. On a technical blog this means version queries. A reader who types "ef core yenilikleri" is most likely asking about the latest release; a post about the new features of EF Core 8, which used to rank well, no longer satisfies readers for this query.

The guidelines' note that "the dominant interpretation of a query changes over time" matters right here. The answer to the query "net lts" has been .NET 10 since November 2025; when a new LTS release ships, the answer will change again. A post that targets a version-dependent query should either carry the version name in its title and stay as that version's page, or be updated with every release. We look at this distinction from the content maintenance angle in the last post of the series.

Classifying Queries by Intent

Let's label the sample export from the previous post by intent this time. A rule-based classifier is not perfect, but it is enough to group hundreds of queries in a first pass and to pick the queries whose SERP you will check by hand.

using System.Text.RegularExpressions;

namespace Bookstore.ContentSeo;

public enum Intent { Navigational, Troubleshoot, Comparison, WhatsNew, HowTo, Definition, Broad }

public static class QueryIntent
{
    // Order matters: the first matching rule wins
    private static readonly (Intent Intent, Regex Pattern)[] Rules =
    [
        (Intent.Navigational, Rx(@"\bbookstore\b")),
        (Intent.Troubleshoot, Rx(@"\bcs\d{4}\b|hatas[ıi]|uyar[ıi]s[ıi]|\berror\b|exception|must contain")),
        (Intent.Comparison, Rx(@"\bvs\b|\bm[ıiu]\b.*\bm[ıiu]\b|fark[ıi]")),
        (Intent.WhatsNew, Rx(@"yenilik|new features|what's new|\b\d+(\.\d+)? (release|sürümü)")),
        (Intent.HowTo, Rx(@"nas[ıi]l|\bhow to\b|geri alma|rollback|\badd\b|add-|bulk|toplu")),
        (Intent.Definition, Rx(@"nedir|\bwhat is\b")),
    ];

    public static Intent Classify(string query) =>
        Rules.FirstOrDefault(r => r.Pattern.IsMatch(query)) is { Pattern: not null } rule ? rule.Intent : Intent.Broad;

    private static Regex Rx(string pattern) =>
        new(pattern, RegexOptions.IgnoreCase | RegexOptions.CultureInvariant);
}

The order of the rules is deliberate: "cs8618 uyarısı nasıl düzeltilir" is both an error code and a "how" question; the reader's real situation is that they hit a problem, so Troubleshoot comes first. The program prints the queries that reach the migration pages and how each page's impressions split across intents.

using System.Globalization;
using Bookstore.ContentSeo;

CultureInfo.CurrentCulture = CultureInfo.InvariantCulture;
string path = args.Length > 0 ? args[0] : "gsc-url-query.csv";
List<SearchRow> rows = [.. (await File.ReadAllLinesAsync(path)).Skip(1).Select(SearchRow.Parse)];

Console.WriteLine($"{"intent",-14}{"query",-40}{"impr",6}{"ctr",6}{"pos",6}");
foreach (SearchRow r in rows.Where(r => r.Url.Contains("migration")).OrderByDescending(r => r.Impressions))
{
    string query = r.Query.Length > 38 ? r.Query[..35] + "..." : r.Query;
    Console.WriteLine($"{QueryIntent.Classify(r.Query),-14}{query,-40}{r.Impressions,6}{r.Clicks * 100.0 / r.Impressions,5:F0}%{r.AvgPosition,6:F1}  {r.Url}");
}

// How each page's impressions split across intents
Console.WriteLine();
foreach (IGrouping<string, SearchRow> page in rows.GroupBy(r => r.Url).OrderBy(g => g.Key))
{
    int total = page.Sum(r => r.Impressions);
    IEnumerable<string> mix = page
        .GroupBy(r => QueryIntent.Classify(r.Query))
        .OrderByDescending(g => g.Sum(r => r.Impressions))
        .Select(g => $"{g.Key} {g.Sum(r => r.Impressions) * 100 / total}%");
    Console.WriteLine($"{page.Key,-46}{string.Join(", ", mix)}");
}

Output of dotnet run (same sample data; percentages rounded down):

intent        query                                     impr   ctr   pos
Broad         ef core migrations                         980    2%  11.3  /en/blog/ef-core-migrations-guide
Broad         ef core migration                          640    1%  14.6  /en/blog/ef-core-migrations-guide
Broad         ef core migration                          420    7%   6.2  /blog/ef-core-migration-rehberi
HowTo         ef core migration nasıl yapılır            310   12%   4.1  /blog/ef-core-migration-rehberi
HowTo         ef core migration geri alma                260    3%   9.8  /blog/ef-core-migration-rehberi
HowTo         ef core migration geri alma                240    5%   7.5  /blog/ef-core-migration-geri-alma
HowTo         dotnet ef migrations add                   210    3%   9.1  /en/blog/ef-core-migrations-guide
HowTo         ef core add-migration                      150    6%   8.4  /blog/ef-core-migration-rehberi
Definition    ef core migration nedir                    130   11%   5.0  /blog/ef-core-migration-rehberi
Troubleshoot  remove-migration hatası                     90   12%   3.2  /blog/ef-core-migration-geri-alma
HowTo         dotnet ef migrations add                    70    1%  18.2  /blog/ef-core-migration-rehberi
Navigational  bookstore blog ef core                      12   50%   1.0  /blog/ef-core-migration-rehberi

/blog/aspnet-core-di-lifetime                 Comparison 79%, Broad 20%
/blog/cs8618-nullable-uyarisi                 Troubleshoot 100%
/blog/dapper-ile-toplu-insert                 HowTo 100%
/blog/dependency-injection-nedir              Broad 66%, Definition 33%
/blog/ef-core-10-yenilikleri                  WhatsNew 100%
/blog/ef-core-migration-geri-alma             HowTo 72%, Troubleshoot 27%
/blog/ef-core-migration-rehberi               HowTo 58%, Broad 31%, Definition 9%, Navigational 0%
/blog/ef-core-vs-dapper                       Comparison 100%
/en/blog/cs8618-non-nullable-property-warning Troubleshoot 100%
/en/blog/ef-core-migrations-guide             Broad 88%, HowTo 11%
/en/blog/what-is-dependency-injection         Definition 60%, Broad 40%

Three things stand out. The TR guide page (/blog/ef-core-migration-rehberi) gets traffic from five different intents; its highest-CTR queries are "nasıl yapılır" and "nedir", the queries the page really answers. For "ef core migration geri alma", on the other hand, the guide page stays at 3% CTR and the separate rollback page at 5%, both in the 7–10 position band. The EN guide page gets 88% of its impressions from generic queries whose language and intent are unclear, but its CTR is 1–2%; for these queries you need to look at the SERP to understand what readers want.

One Page or Separate Pages?

Back to the four developers from the beginning. Two questions are enough for the decision: do the intents want the same content, and does Google show the same results for these queries? If the first-page results of two queries largely overlap, you can assume Google most likely treats them as the same intent; a single page can answer both. This is an industry practice, not a rule documented by Google. If the results differ, separate pages are the better choice.

For the Bookstore example this leads to the following decision: "nedir" and "nasıl yapılır" stay on the same guide page; readers move from the concept to the command in a natural order. Rolling back is a separate Do intent, and if forum answers and short posts dominate its SERP, it deserves a separate, focused page. But then the guide page should not target the rollback query; the guide's rollback section should cover it in a few sentences and link to the separate page. "remove-migration hatası" becomes a section of the rollback page, because readers hit that error while rolling back. Keeping the two pages from competing for the same query is the subject of the next post.

In Production

Add an "intent" and a "format" column to the keyword map. Filling in these two columns by looking at the target query's SERP before you start a new post prevents a post written in the wrong format from the outset.

Use the classifier as a rough filter. The rules try to catch Turkish and English phrasings, but they drop queries like "dependency injection lifetime" into Broad. Always make the decision by looking at the SERP.

Look per language. The TR and EN SERPs for the same query can differ; Turkish results may be dominated by forums and videos while official documentation ranks first in English.

Record the SERP with a date. Keeping a dated screenshot or note of a query's first page lets you see when the intent changed.

Common Pitfalls

Forcing the format you prefer. Writing a 5,000-word guide when the query wants a two-line answer, or telling a story when the reader expects a comparison table. The format is chosen by the reader's intent, not the author's preference.

Not updating content when the intent changes. When a new release ships, the answer to "ef core yenilikleri" changes; the page about the old release answers the wrong intent now, even if its title stays the same.

Looking at one query and forgetting the family. The ambiguity of "ef core migration" is resolved in the family's longer and clearer queries; you need to read them one by one.

Treating intent classes as a content calendar. You do not need a post for every intent; intents that the same page answers naturally should stay on that page.

A Small Experiment

★☆☆ Pick a query from your own field and look at its TR and EN SERPs in a private window. Note the formats of the top five results (documentation, blog, forum, video); is there a difference between the two languages?

★★☆ Add a "Reference" intent to QueryIntent that catches phrases such as "cheat sheet", "parametreleri", "options" and "syntax". In your own query list, is the CTR of the queries that fall into this intent different from the others?

★★★ Pick two queries from the same family and record the URL lists of their top ten results by hand. Write a small C# function that computes the share of common URLs and suggests "separate pages" when the share is low.

In this post we looked at the intent of individual queries. In the next post we step back and look at the site as a whole: topic clusters, series and category structure, and keyword cannibalization, where two pages that target the same intent weaken each other.