SEO Copywriting

SERP analysis before writing – what exactly I record

SERP analysis answers three questions: what format Google expects for the query, what every top result has in common, and what all of them are missing. The answer to the third question is where the idea for an article with a real reason to rank higher comes from.

I go through the top ten results in a private window, on desktop and on mobile, and fill in the same row of a spreadsheet for each one.

In parallel I ask several AI assistants the same question and note which sources they cite and which follow-up questions they split the topic into. I describe how I find those questions in the post on keyword research and query fan-out.

When I tell you an article is the wrong move

• The top results are product pages or store categories. Google sees purchase intent, and a blog guide rarely beats a page where you can buy.
• Tools dominate the results (calculators, converters, search tools). An article won't replace a working tool.
• Local results and a map sit on top. Your Business Profile and a location page matter more than a post.
• The query is really a competitor's brand name. Writing for someone else's name seldom brings traffic that turns into clients.

The first-hand element – where I get it for every article

A first-hand element is the part of an article that can't be rebuilt from other pages or generated by a language model: data, a test, an implementation story, an opinion grounded in experience. It decides whether the piece is yet another version of the same thing or a source worth citing.

Google's May 2025 post on doing well in AI search encourages unique, "non-commodity" content, and its guidance on high quality reviews (updated December 2025) explicitly asks for evidence of first-hand experience: visuals, measurements, comparisons. So before I write, we agree which of the types below your company can realistically provide.

If none of these can be obtained, I say so before starting. Then we either switch to a topic where the company has something to say, or book the interview described below.

Expert interviews – turning in-house knowledge into content

An expert interview is a short, prepared conversation with someone in your company who knows the topic from practice. One call usually yields material for the whole article: examples, exceptions, figures from daily work and opinions that no other page has.

How it runs

1. The day before, I send the expert the questions and a draft outline so they know what I'm after.
2. We talk online; I record with permission and transcribe.
3. From the transcript I pick passages that fill the gaps found in the SERP analysis and mark them in the draft.
4. Quotes and facts go back to the expert for approval together with the finished article.
5. If the expert will be the author or reviewer, I draft a short bio and we agree on the byline.

Questions I ask almost every time

• What do clients ask most often before they buy or sign?
• What do people get wrong here, and what does it cost them later?
• Where do you disagree with what others in the industry write?
• What does this process look like at your company, step by step, and where does it usually stall?
• When do you talk a client out of this solution?
• What data from your work could we show without exposing clients?

Types of SEO articles and how their structure differs

Structure follows intent, not a single template. A how-to, a comparison and a pricing article answer different questions, so they have different mandatory parts and a different place for the call to action.

Comparisons and rankings need the most care. Google's guidance on high quality reviews (updated December 2025) expects, among other things, an explanation of what sets products apart, pros and cons based on your own research, a justification for any "best" pick, and ranked lists that stand on their own. If the company has no experience with the options being compared, I advise against a ranking and propose a piece on selection criteria instead.

Title, meta description and URL – how I write them and why Google rewrites them

The title and meta description are the first thing a searcher sees, but Google treats them as a suggestion, not an instruction. Well-written ones are more likely to be shown as they are.

According to Google's documentation on title links (updated December 2025), the title element has no length limit; in results it is truncated to fit the device width. Google may generate its own title when the original:

• is incomplete, for example has an empty part before or after a separator,
• is outdated, for example contains an old year that conflicts with the visible heading,
• doesn't accurately describe the page,
• is the same boilerplate across many pages,
• competes with several headings of similar weight, so no main title is clear,
• is in a different language or script from the content,
• repeats the site name that Google already shows in the result.

Descriptions work the same way. Google's snippet documentation (updated April 2026) says snippets are created primarily from page content, and the meta description is used when it describes the page more accurately. There is no length limit; descriptions should be unique per page and genuinely descriptive, not a list of keywords.

My rules

• Title: main phrase first, around 60 characters in total so the important part shows on mobile, no year unless I commit to updating it every year.
• H1: same topic as the title, but it can be longer and more natural. Exactly one per page.
• Meta description: 120–160 characters, full sentences, a concrete promise of what's inside, never cut off mid-thought.
• URL: short, includes the phrase, no dates or words that will age. I don't change it after publishing.
• Variants: you get two alternative titles so we can test another one after a few weeks if CTR is low.

Fact-checking and sources – my protocol

Every number, date and quote in my articles has a source I checked myself, and that source is named in the text. It's the simplest way to make a piece credible to readers, to Google and to AI models, which like to cite passages with specifics.

1. Primary source, not a middleman. If a blog quotes a statistic, I look for the report or documentation it came from. If I can't find it, the number stays out.
2. Date and scope. I note when the data was collected and which country and sample it covers. A US study from a few years ago is described as exactly that, not as a fact about your market.
3. Exact wording. I compare the figure with the original, including the unit and whether it's a median, a mean or a share.
4. Publisher and year in the sentence. I write "according to Google's 2026 documentation", not "studies show". A paragraph like that can be quoted without context.
5. A source list under the article with links, so editors and readers can check.
6. Link checks after publishing. A dead link to the report behind a figure undermines the whole paragraph, so I check links again during updates.

Topics where a mistake can hurt someone

Google's Search Quality Rater Guidelines (September 2025 version) define YMYL topics by the risk of harm to people's health, safety or financial stability, or to the welfare of society, and note that most topics are not YMYL. For health, finance or legal pieces I require a review by a suitably qualified person on your side and show them on the page as the reviewer. Without that I don't take the article, which is also listed under "not for you".

Editing in practice – the same paragraph before and after

The difference between text written "for SEO" and text that ranks and gets cited is easiest to see in a single paragraph. Below is a typical version I get to fix and the version after my edit, using the question of title length.

What changed:

• The first sentence answers the question instead of announcing it.
• An unverifiable claim about rankings is gone, replaced by a fact with a source and a year.
• The paragraph ends with the author's decision and the reason for it, which is the experience element.
• Filler is cut ("in today's digital landscape", "extremely important", "worth keeping in mind").

I edit a client's existing article the same way. I go deeper into paragraphs that AI models pick for answers in How to write content AI cites, and into the limits of using AI for writing in the post on AI content and Google policy.

What you get with the article – on-page elements ready to ship

I hand over an article as a ready-to-publish package: text, metadata, image proposals, links and structured data. If I have access to your CMS, I publish it myself; if not, you get instructions on which field takes what.

Details developers ask about most

• Author in structured data: Google's Article documentation (updated September 2026) recommends a separate entry per author, only the name in author.name, and author.url or sameAs pointing to a page that identifies the person. If the site already defines a Person entity, I reference its @id instead of redefining the author.
• Dates: the visible date and dateModified must match. Google also asks that the date describe when the page was published or updated, not the event the article is about.
• FAQ at the end: I add questions when they help the reader, but I don't promise rich results. Since August 2023 Google shows FAQ rich results mainly for well-known, authoritative government and health sites.
• Link anchors: the test in Google's documentation is simple: read the anchor text alone and check whether it's clear where it leads. "Click here" fails it.

If your site doesn't yet have a sound article template (author, dates, structured data), that's a separate job under Schema.org implementation. Types and properties are covered in the structured data guide.

The first 90 days after publishing – how I judge an article and what I fix

I don't judge a new article after a week. For the first three months I check in Search Console whether it's indexed, which queries it shows up for and how impressions move, and only then decide on changes.

Traffic from AI Overviews and AI Mode is counted in Search Console's regular performance report, so I check presence in AI answers separately by asking assistants the questions from the brief. How to set up tracking for visits from ChatGPT and Perplexity in GA4 is in How to measure traffic from ChatGPT, Perplexity and AI Mode. Older posts that lose traffic over time are a different problem, covered in the post on content decay.

What I need from you and how I hand the article over

I don't need much to write a good article, but a few things are essential. Without them the piece will be correct, but it won't have the edge you're paying for.

• Access to an expert for a short call, or written answers to the questions above.
• Read-only Search Console access, to see which queries the site already appears for and make sure the new piece won't compete with an old one.
• Offer details: which service or product the article should lead to and what sets it apart.
• Brand rules, if you have them: tone, banned words, how to address the reader.
• One approver who collects the team's feedback, rather than several parallel threads.

You get the text in a document with comments explaining the key decisions (why this title, why this section, which source backs a figure). I write the Polish version from scratch rather than translating, and if you publish in several languages I make sure the versions are linked, as described in the post on hreflang and international SEO.

When an article alone isn't enough

A single article solves the problem of one topic. If weak visibility has a different cause, a better text won't change much, so before ordering it's worth checking whether you're in one of these situations.

How related articles build topical authority is covered in the post on topical authority and topic clusters.