What Is Content SEO? People-First Content, the "Who, How, Why" Questions and Search Engine-First Warning Signs

Version note: This post is based on the November 2026 state of Google Search Central's people-first content guide, its spam policies and its generative AI content guidance (last changed on 1 October 2026).

Guess First

The Bookstore team's technical blog has been live for a year. In quarterly planning, the teammate who owns content brings three proposals: (1) let's produce 20 new posts a week with AI and pick topics from the terms rising in Google Trends that week; (2) every post should be at least 2,500 words, because "Google loves long content"; (3) let's move the date of old posts to today every month so they look "fresh". Which of these three does Google's own guide explicitly list as a warning sign? Which one can do more than fail to help rankings and actually harm the site as a whole?

Answer: all three. To see why, let's pin down the definitions first. SEO is the work of making a site discoverable in search engines and making its pages the ones chosen as answers to queries; content SEO is the content side of that work.

What Is Content SEO? How It Differs from Technical SEO

It helps to think of SEO in two layers. The technical layer makes the page findable: crawlable URLs, correct status codes, canonicals, sitemaps, hreflang, rendering. We built all of that on ASP.NET Core in the Technical SEO series. The content layer makes a page that has been found get chosen as the answer to a query: does the page answer the right question, is the answer trustworthy, does the reader find what they came for and leave satisfied?

The infrastructure can be flawless, but an indexed page that adds nothing for the reader will not rank anywhere. The reverse is true as well: an excellent post that cannot be crawled reaches nobody. Google's SEO Starter Guide is clear on this: of everything in the guide, compelling and useful content is what will likely influence search presence the most. So content SEO is not "sprinkling keywords into text"; it is writing the right topic, for the right intent, in the right structure, and keeping it alive over time.

This series works through that in seven posts: deciding what to write (keyword research and search intent), organising what you have written (content architecture and internal linking), and writing and maintaining (pages that answer and content maintenance). The working example is the site you are reading: mertozen.com's category, series and post structure. We covered the crawl, index and ranking mechanics in the first and third posts of the SEO Fundamentals series; here we only look at the content side.

What Google's People-First Content Guide Says

Google's "Creating helpful, reliable, people-first content" page is built around a single idea: ranking systems try to surface content made to benefit people, not content made to influence search engines. The page does not describe an algorithm that measures this; instead it gives groups of questions a creator can ask about their own work. Rather than copy those questions item by item, here is what they ask, in our own words:

• Content and quality: Does the post contain original information, research or analysis? If it summarises other sources, does it add something on top? Does the title describe the content honestly or does it exaggerate?
• Expertise: Can the reader see where the information comes from and why the author is talking about this topic? Are there errors that could be easily verified?
• Presentation: Does the text look sloppy or mass-produced? Do ads or distractions get in the way of the content?
• Comparison: Does this page offer more value than the other results for the same query? When readers leave the page, have they found what they wanted, or do they have to search again?

The guide adds two practical suggestions: have someone unaffiliated with your site, who will give you an honest opinion, review the content, and run an audit starting with pages that lost traffic. We will do the latter with Search Console data in the last post of the series.

A note: in 2024 Google stopped using a separate "helpful content system" and folded these signals into its core ranking systems (we covered this in the "SEO Myths and Facts" post of the SEO Fundamentals series). These questions are therefore part of the general logic of ranking, not of a separate filter.

Applying It to a Post: An Example from mertozen.com

To keep the questions concrete, let's apply them to a real post on the site: the first post of the Structured Data and Schema.org series, "What Is Structured Data? Schema.org, JSON-LD and What Google Actually Does with It".

The value of the table is in the right-hand column: the helpful content questions do not produce a score, they produce a to-do list. In this example the list is short and concrete: link the byline to the author page, give sources in a form readers can reach, and decide how to describe the production process.

Who, How, Why

Who: who wrote it?

The guide's "Who, How, and Why" section boils the quality questions down to three concrete headings. The first is the author. According to Google, readers should be able to see easily who created the content; there should be a byline where readers expect one, and the byline should lead to more information about the author. On a technical blog that means a name at the top of the post, linked to an "About" page that says what the author works on, which technologies they use and where their external profiles are.

On mertozen.com the byline currently appears as the site name, "Mert Özen", in plain text; on the JSON-LD side the post is marked up as a BlogPosting, the author as a Person and the About page as a ProfilePage. In other words, the connection exists for machines but not for readers. Turning the byline into a link to the About page is a one-line Razor change and matches the guide's advice exactly.

The guide's warning in this section matters too: creating a fake author identity with AI-generated headshots, made-up names or false credentials misleads readers and is a sign of low quality. Using a team name such as "Bookstore Engineering" on a team blog is fine; inventing a person who does not exist is not.

How: how was it produced?

The second heading is the production process. Google raises this question especially for product reviews: how many products were tested, what were the results, where are the photos? The equivalent for a technical blog is obvious: was the code run, is the output real, which version was it tried with? When a reader arrives with an error message, this is how they judge whether the fix in the post will work in their environment. The "Version note" line at the top of every mertozen.com post is exactly this signal: it states which .NET version the code was built with and which package versions it was tried with. Showing compiler warnings, HTTP responses and test output from real runs continues the same signal. A made-up output gets noticed on the reader's first try.

On automation and AI, the guide says this: if a substantial part of the content was produced with automation or AI, it is right to explain how and why it was used wherever readers would reasonably wonder. Google's February 2023 post on AI content adds two details: listing AI as the author in the byline is not the recommended way to disclose it, and AI-generated content gets neither a special advantage nor a special penalty; the criterion is still whether it is helpful, original and reliable. On a technical blog the natural place for such a disclosure is the version note line, which already describes the production process, or a general "How this blog is written" section on the site.

Why: why does it exist?

The third heading is the most fundamental: why was this page created? The guide's answer is clear. The primary purpose should be to help people who come to the site directly. If the primary purpose is to attract visits from search engines, the content is not aligned with what Google tries to reward; using automation to manipulate rankings is a spam policy violation.

In practice you can use this test: would you write this post even if you knew it would never get traffic from search engines? For a post that completes a series and that readers will need at their next step, the answer is "yes". For a post opened because "this keyword gets a lot of searches, let's write something", the answer is usually "no".

Search Engine-First Warning Signs

The guide also lists, as questions, the signs that content was made for search engines. Let's look at them with their technical blog equivalents:

Chasing trends. Picking a topic because it is popular this week, not because it suits your existing audience. A cryptocurrency exchange review suddenly appearing on Bookstore's .NET blog is an example. The first planning proposal, picking topics from terms rising in Trends, fits this sign directly.

Entering a niche without expertise. Writing about a topic you have never worked with because it promises traffic. Like a .NET team writing a comparison of a mobile framework it has never used.

A word count target. Google has no preferred word count; the guide says so explicitly. A "2,500 words per post" rule pushes posts on questions with short answers to be padded with filler. The second proposal lands here.

Freshness by changing dates. Updating the publication date without substantial changes to the content, or adding and removing content just to "look fresh". The guide says this does not help. The third proposal is exactly this.

Retelling other people's content. Rewriting a Microsoft Learn page in Turkish without adding any experiment, measurement or commentary. Readers get the same information better from the source itself.

Promising an answer that does not exist. Opening a post titled ".NET 12 release date" for a version that has not been announced and giving no date in it.

Heavy automation across many topics. Producing pages in bulk with automated tools so that many topics are covered. This sign takes us to the spam policies.

The Scale Limit: Scaled Content Abuse

Scaled content abuse, one of Google's spam policies, describes generating many pages primarily to influence rankings rather than to help readers. The key point of the policy is that how the content is produced does not matter: whether by hand, with templates or with AI, many pages that add little value count as a violation. The policy's examples include using generative AI to produce many low-value pages, taking search results or feeds and transforming them with synonyms or translation, and stitching together pieces from different pages without adding value.

Google's generative AI content guidance turns that line into practical steps: AI output should be fact-checked and reviewed before publishing, and this applies not only to the body text but also to titles, meta descriptions, structured data and image alt text. The guidance was updated on 1 October 2026 and now also points to the Search Quality Rater Guidelines sections that cover scaled content and content made with little effort or originality. Rater evaluations do not change rankings directly, but they show what Google considers low quality.

Back to Bookstore's first proposal: 20 AI posts a week is not a violation in itself. Whether it is one depends on what each post adds for the reader and who verified what before publishing. Twenty posts that go out without run code, real output and a human check come very close to what the policy describes.

In Production

Add a pre-publish check step to your CMS. Three required fields on the post form are enough: the author (a real person or a team), a verification note (version, environment, commands run) and the reader question the post answers. If the third field stays empty, the post has no answer to the "Why" question.

If you use AI, record the workflow. Who produced the draft, who ran the code, who checked the sources? This helps both when you write a disclosure and when you need to find the root of an error later.

Set a volume limit. A pipeline that produces content should have a daily or weekly cap and a human approval before publishing. Scale problems usually grow before anyone notices.

Keep the date fields separate in the CMS. The publication date never changes; the updated date only moves when the content changes substantially. Editors should not have a "move the date to today" button. We will come back to this in detail in the last post of the series.

Common Pitfalls

Losing the difference between "writing for SEO" and "writing for readers and making it findable". The first picks topics and text for the search engine; the second writes for the reader's question and then removes the technical and content obstacles that keep the post from being found. The guide's "What about SEO?" section also sees SEO in the second sense, as support applied to people-first content.

Thinking E-E-A-T is a direct ranking factor. Both the people-first guide and the SEO Starter Guide say it is not a specific ranking factor. Google uses a mix of factors that can identify good E-E-A-T; there is no such job as "raising your E-E-A-T score". The details are in the SEO Fundamentals post "How Google Ranks: Ranking Systems, Core Updates and E-E-A-T".

Thinking that disclosing AI use will be penalised. Google's criterion is the value of the content, not how it was produced. Hiding it puts the reader's trust at risk.

Ticking off the self-assessment questions like a checklist. The goal of the questions is not to collect "yes" answers but to find concrete work for each post, like the right-hand column of the table above.

A Small Experiment

★☆☆ Pick a page from your own blog or your team's documentation and fill in the table above for it. Do you get at least two concrete tasks in the right-hand column?

★★☆ List the titles of the posts you published in the last six months and write the answer to the "Why" question next to each in one sentence. Mark the ones whose answer is "it got a lot of searches" and reassess what those posts give readers.

★★★ In the CMS you use, or in an ASP.NET Core publishing endpoint, write a check that blocks publishing when the author, verification note or target reader question fields are empty. Add a separate approval field for drafts produced with AI.

In this post we saw what not to write and how Google describes good content. The next question is what to write: in the next post we look at finding topics and queries for a technical blog, from our own Search Console data to Keyword Planner, together with what each source does and does not show.