This is the second post in a series about building a 110-post SEO content strategy from scratch. If you missed the first one, start here for the full overview.
Most businesses approach keyword research the same way. They find a tool, type in their industry, get a list of terms with search volumes, pick the ones that look promising, and hand them to a writer. The writer produces content. The content gets published. Nothing ranks.
The missing step is not better keywords. It is understanding which page on the website each keyword belongs to and why. A keyword does not exist in a vacuum. It needs a home. And that home needs to be the right type of page for the intent behind the search.
Without that mapping, you end up in one of two bad situations. Either you create blog posts competing against your own service pages for the same keywords, or you create service pages targeting keywords that should be blog content. Both confuse Google and split your ranking potential instead of concentrating it.
For the Tiger Tail project, the website had two distinct types of pages before a single blog post was written. Service pages and industry pages. Each type needs its own keyword logic.
Service pages target keywords where the searcher is looking for a solution or a provider. Someone searching “ai strategy consultant” or “workflow automation services” has commercial intent. They are not looking for an explanation. They are looking for someone to hire. These keywords belong on service pages, not blogs.
Industry pages target keywords where the searcher is a specific type of business looking for AI solutions relevant to their sector. Someone searching “ai for law firms” or “ai for real estate agents” has commercial intent too, but with an industry-specific lens. These keywords belong on the industry pages, not the blog either.
Blog posts serve a different purpose. They capture informational searches from people who are not ready to buy yet but are researching the problem. The blog content feeds authority to the service and industry pages. The pages convert. The blog attracts.

Service pages and industry pages target buyers. Blog posts target researchers. Mixing them up is one of the most common and most damaging SEO mistakes a business can make.
Here is what the keyword-to-page mapping looked like for the Tiger Tail service pages. Every page got its primary keywords and monthly search volumes confirmed before any content was briefed.
service-page-keyword-map.txt
Page URL Primary Keyword Monthly Searches
/services/ai-audit-strategy ai strategy consultant 880
/services/ai-audit-strategy ai readiness assessment 720
/services/ai-audit-strategy ai implementation consultant 390
/services/ai-audit-strategy automation consultant 480
/services/workflow-automation business process automation services 320
/services/custom-ai-development custom ai development company 480
/services/custom-ai-development ai integration services 590
/services/growth-engineering ai marketing automation 720
/services/growth-engineering ai lead generation agency 110
/services/ai-training-enablement corporate ai training 40
And here is the same mapping for the industry pages:
industry-page-keyword-map.txt
Page URL Primary Keyword Monthly Searches
/ai-for-legal ai for law firms 1,300
/ai-for-real-estate ai real estate agent 590
/ai-for-real-estate ai for real estate agents 480
/ai-for-healthcare healthcare workflow automation 170
/ai-for-finance-accounting ai for accounting firms 70
/ai-for-home-services ai for contractors 110
/ai-for-legal legal document automation 170
/ai-for-healthcare ai for medical billing 90
Looking at this data together, the legal page stands out immediately. “Ai for law firms” at 1,300 searches per month is the single highest-volume keyword across all pages on the site. That tells you the legal cluster needs serious depth in the blog to give that page the authority it needs to compete.
The corporate AI training page, on the other hand, targets “corporate ai training” at just 40 searches per month. That is a low-volume keyword but the commercial intent behind it is very high. Someone searching that phrase is almost certainly a business ready to spend money on training. Low volume does not mean low value.
This is the part most keyword guides miss. Search volume is not just a filter for deciding which keywords to target. It is an input for prioritising which content to build first and how much of it you need.
A page targeting a keyword with 1,300 monthly searches needs more supporting blog content around it than a page targeting 40 monthly searches. Not because the second page matters less, but because Google needs to see more topical depth before it will trust a new domain with a high-volume, competitive keyword.
volume-to-priority-logic.txt
Volume Range What It Means Content Priority
1,000+ High demand. High competition. Deep cluster needed.
Big brands likely dominating page 1. 10+ supporting posts.
New domain needs time and authority.
300 to 999 Solid demand. Beatable competition Strong cluster needed.
with quality content and good structure. 8 to 10 supporting posts.
100 to 299 Moderate demand. Often less competitive. Medium cluster.
Good early target for a new domain. 6 to 8 supporting posts.
10 to 99 Low volume. Often high commercial intent. Focused cluster.
Worth targeting if buyer intent is clear. 5 to 6 supporting posts.
Under 10 Very niche. May still be worth it Evaluate carefully.
if the buyer value per conversion is high. Single post may be enough.
This framework shaped the entire cluster structure for the project. The legal cluster targeting 1,300 searches got ten posts. The AI training cluster targeting 40 searches also got ten posts, but those posts are written differently. More specific, more technical, more conversion-oriented, because the person reading them is further along in their decision.

Search volume tells you how many people are searching. Search intent tells you why. Getting the intent wrong is worse than targeting a low-volume keyword because it means you are attracting the wrong people even when you do rank.
Every keyword in the Tiger Tail mapping got an intent classification before it was assigned to a page. The classification is simple but it matters every time.
search-intent-classification.txt
Intent Type What the Searcher Wants Right Page Type
Informational Learning about a topic. Blog post.
Not ready to buy yet.
Example: "what is ai readiness assessment"
How-To Looking for a process or steps. Blog post or guide.
Example: "how to automate workflow"
Commercial Researching providers or solutions. Service or industry page.
Getting close to a decision.
Example: "ai strategy consultant"
Comparison Evaluating options. Blog post or landing page.
Example: "make vs zapier vs custom automation"
Transactional Ready to buy or contact. Service page with clear CTA.
Example: "hire ai implementation consultant"
A keyword like “what is an ai readiness assessment” is informational. It belongs in the blog as a post that educates the reader and links to the service page at the end. A keyword like “ai readiness assessment” with no qualifier is commercial. Someone typing that is likely comparing providers. It belongs on the service page itself.
Those two keywords look similar. They would land on completely different pages in a well-structured site. Getting that distinction right is what separates a site that converts from one that attracts traffic that never does anything.

Putting commercial intent keywords on blog posts and informational keywords on service pages is one of the most common ways content strategies fail quietly. The traffic numbers look fine. The conversions never come.
Here is what the approach looks like without mapping versus with it:
before-vs-after-mapping.txt
WITHOUT KEYWORD MAPPING
"Let's write a blog about AI for law firms."
"Let's write about what an AI consultant does."
"Let's cover AI pricing."
Result: Random posts. No page authority built.
Service pages get no support.
Blog competes with its own pages.
Nothing ranks for anything meaningful.
WITH KEYWORD MAPPING
"ai for law firms" (1,300/mo, commercial) → /ai-for-legal service page
"how small law firms use ai" (informational) → blog post in legal cluster
"ai contract review" (informational/how-to) → blog post in legal cluster
"legal document automation" (170/mo, commercial) → /ai-for-legal page
"ai and billing ethics law firms" (informational) → blog post in legal cluster
Result: Service page targets commercial keywords.
Blog cluster builds topical authority around it.
Every post links back to the parent page.
Google sees depth and relevance. Rankings follow.
The difference is not subtle. In the first approach, a business is just publishing. In the second, every piece of content has a specific job to do and a specific place in the architecture.

By the time the keyword mapping was done for the Tiger Tail project, every page on the site had a clear primary keyword, a confirmed search volume, an intent classification, and a list of supporting blog topics that would feed it authority over time.
That groundwork meant every brief written after it had a reason to exist. Not just “here is a topic someone might find interesting” but “here is a keyword a real person searches for, here is the page it supports, here is how it fits into the cluster that will eventually rank the parent page.”
Keyword mapping is not a research exercise. It is a structural decision. It determines what gets built, where it lives, and what it is supposed to accomplish. Every hour spent on it saves ten hours of rewriting content that landed in the wrong place.
With the keyword map in place, the next step was research. Not the generic kind where you read a few articles and summarise them. Proper data-backed research using Perplexity Sonar that produced real statistics, named sources, and proof points for every single post across all 110 briefs.
That process is what I cover in the next post: how I use Perplexity Sonar to research blog topics with real data.
If you want to talk through what keyword mapping would look like for your own website, book a call. I can usually tell within the first conversation whether a site’s content architecture is working for it or against it.
See how I approach SEO strategy →
Dhruv is an SEO consultant working with business owners, founders, and agencies. If organic search is not delivering for your business, this is where to start.
If you have not read the earlier posts in this series, start here to understand why most blogs fail and here for the competitor research approach.
The first problem is not knowing what to write about when competitor data is not an option. Either nobody in the niche is blogging with measurable results, the industry is too specific for competitor keywords to be meaningful, or the business simply wants to create content on its own terms rather than chasing what others are ranking for.
The second problem is that even when topic ideas exist, they never become a consistent publishing schedule. A blog calendar gets created in a meeting, lives in a Google doc for two weeks, and then quietly disappears. Publishing becomes irregular. Months go by. The blog never builds the compounding value it was supposed to.
These two problems look different on the surface but they come from the same place: there is no system underneath the content. The persona approach solves both at once. It gives you a method for generating months of relevant topics and a calendar that is specific enough to actually use.
Keyword research tells you what people are searching for. Persona research tells you why they are searching for it and what they actually need when they get there.
Both matter. But for building long-term authority and genuine trust with your audience, persona-driven content wins. It speaks directly to the person behind the search rather than just matching the query. Readers feel understood. That is what makes them come back, share the content, and eventually reach out.
Content written without persona thinking tends to feel generic even when it is technically accurate. It covers the topic but it does not resonate with anyone in particular. It gets read and forgotten. It builds no relationship and no trust.
A blog that speaks to a specific person with a specific problem will always outperform a blog that speaks to everyone about a general subject. Specificity is what builds authority.

A buyer persona is a detailed profile of an ideal customer. Not a demographic summary. A real picture of the person: their job role, their industry, what their day looks like, what keeps them stuck, what they are trying to achieve, what they search for when they have a problem, and what kind of content actually helps them make decisions.
Most businesses either have no defined personas or have ones that are too vague to be useful. Something like “marketing manager, 30 to 45, works at a mid-sized company” is not a persona. It is a demographic filter. A useful persona includes the specific frustrations, the exact questions they type into Google, and the outcomes they are trying to reach.

The good news is that you do not need a formal persona document to start. A rough description from someone who knows the customers well is enough to build on.
The content is technically correct but feels like it could have been written for anyone. There is no consistent point of view. The topics jump around instead of building a coherent body of knowledge in one area. Readers do not feel like the brand actually understands their situation. They read, get the information they needed, and leave without ever considering the business behind the content.
Trust does not come from being informative. It comes from being specifically relevant to the person reading. That only happens when the content was built around a real understanding of who that person is.
Ask the business directly. Most will give you two to four personas without much prompting. What you need from each one: job title or role, the industry they work in, their biggest daily challenges, and the outcomes they are trying to achieve. If the business has never formally defined their personas, a rough description is fine to start. You are building a foundation, not a final document.
Open an AI tool that supports Deep Research mode. This feature allows the model to actively search the web rather than drawing only on its training data. That means the persona research it returns is grounded in current, real information: forums, communities, Reddit threads, LinkedIn discussions, industry publications, and survey data where it exists. This is what separates useful persona research from generic assumptions.
Feed the AI the business name and URL, a brief description of what it does and who it serves, the buyer personas, and the target location. Then ask it to research each persona in depth and return a specific number of blog topics based on what it finds. Here is the exact prompt to use:
I am building a blog content strategy for [Brand Name].
The website is [URL].
The brand [describe what it does and who it serves].
The buyer personas are:
[List each persona with job title or description]
Target location: [country or region]
Please use deep research to give me a detailed breakdown
of each persona including:
- Who they are
- Their biggest pain points and daily challenges
- The questions they commonly search for online
- The type of information they look for before making decisions
- What content would genuinely help them
After completing the research, generate [number] blog topic
ideas directly based on the pain points and questions you found.
Topics should be educational and informational, not promotional.
Format the topics as a numbered list.
Once you have the topic list, disable Deep Research. The next step is a formatting and planning task, not a research task. Keeping Deep Research on slows things down without adding value at this stage.
Paste the topic list back into the AI and ask it to turn those topics into a structured blog calendar. Here is the prompt:
Using the blog topics listed above, please create a blog
calendar for [Brand Name].
Starting month: [month and year]
Blogs per month: [number]
Total duration: [number of months]
For each blog topic include:
- The topic title
- A brief content outline covering the key points
- The target buyer persona this post is written for
- A suggested publish date
Format this as a table with four columns:
Topic Title | Content Outline | Persona | Publish Date
So I can copy it directly into a spreadsheet.
In one working session, you now have a 3 to 6 month blog calendar with clear topics, content outlines, persona targeting, and publish dates. A writer can start immediately without further briefing. A client can review it as a deliverable.

The obvious output is a publishing plan. But the less obvious output is the removal of decision fatigue. One of the main reasons blogs become inconsistent is that every publishing cycle starts with the question of what to write next. That question never fully gets answered, the deadline passes, and the blog goes quiet for another month.
With a calendar in place, that question is already answered for the next six months. The only job left is execution. That shift from deciding to doing is what makes consistent publishing actually happen in practice rather than just in plans.
For consultants and agencies, the calendar also works as a client deliverable. It demonstrates strategic thinking beyond just writing. It shows that the content has a reason to exist, a defined audience, and a structure that builds toward something over time.
One blog post almost never produces meaningful results on its own. SEO from blogging is a compounding activity. The value builds as more posts are published, more keywords get covered, and Google increasingly recognises the website as a trustworthy source on a specific set of topics.
A business that publishes four well-targeted posts per month for six months has 24 pages competing for organic traffic. A business that publishes randomly has gaps, inconsistency, and a much weaker topical authority signal. Google notices the difference.

The calendar is not just a content planning document. It is the system that makes compounding SEO possible by turning irregular publishing into a predictable habit.
Topical authority does not come from one great post. It comes from consistent coverage of a specific subject area over time. Google needs to see a pattern before it starts treating a website as an authority on anything.
The competitor approach works best when there is proven search demand in the niche, multiple competitors are already getting blog traffic, and the primary goal is capturing a share of existing organic traffic as efficiently as possible.
The persona approach works best when the industry is niche or specialist, competitors are not actively blogging, the business wants to build a distinct voice, or the goal is long-term audience trust rather than short-term traffic volume.
The strongest content strategies use both. The competitor approach fills the calendar with high-demand topics that have a direct path to organic rankings. The persona approach fills the gaps with audience-first content that builds deeper relevance and trust over time. Together they cover both the traffic goal and the authority goal that I wrote about in the first post in this series.
A blog calendar built on real persona research gives you months of direction in a single session. But the research is only as good as the understanding of the audience behind it. If you want to build a content strategy that is actually tailored to your customers and your business goals, this is something I work through with clients directly.
Whether you need a full content strategy, help with SEO, or a conversation about what your blog should actually be doing for your business, book a call and we can get into the specifics.
See how I approach content and SEO strategy →
Dhruv is an SEO consultant working with business owners, founders, and agencies. If you want a blog that actually builds something, this is where to start.
Published by Dhruv — SEO Consultant for Agencies & Businesses
I built an AI workflow to write long-form blog content at scale. It took four rounds of iteration, broke in four different ways, and never fully hit the original word count target. But it now produces a clean, on-brand 1,300 to 1,450-word draft in about 3 minutes, costs $0.20 per post, and needs only 5 to 10 minutes of human editing. Here is exactly what happened, what failed, and what I actually ended up with.
I want to start with something most AI content posts will not tell you: the first version was pretty bad.
Not unusable. Not embarrassing. But nowhere near what I needed. And the gap between “it kind of works” and “I would actually publish this” took a lot longer to close than I expected.
This is the honest version of that story.
The goal was a repeatable system for long-form blog content. Each post needed to land between 1,950 and 2,100 words, follow a specific structure, carry 4 to 5 internal links placed naturally, stay within short readable paragraphs, and sound like it was written by someone who actually knows the industry. No filler. No generic advice dressed up as insight.
Before this system existed, one blog post took 4 to 5 hours of combined writing and editing time, and cost anywhere from $50 to $150 depending on who was writing it. Across 52 posts a year, that is 208 to 260 hours and up to $7,800. Those numbers made it very easy to justify building something better.
The first approach was simple. Write one prompt, get one blog post. It seemed reasonable.
What actually happened was that the model would write a decent introduction and a solid first section, then quietly start losing structure. By the time it reached the middle of the article, paragraphs were getting longer, sections were getting thinner, and the whole thing just stopped around 950 to 1,200 words. About half of what I needed.

The links were almost never there. When they were, they appeared once, usually in the wrong section. Paragraph length crept up to 90 to 150 words regularly. The brand voice held for the first third and then drifted.
The lesson from round one was simple: a single prompt cannot hold the shape of a long article. The model does not forget what you asked for, but it does lose discipline over distance.
The fix seemed obvious. Break the article into two prompts. First prompt handles the introduction and the first three sections. Second prompt handles the remaining sections, the checklist, and the close.
This was better. The structure got more consistent and the output felt more controlled. But two new problems appeared almost immediately.
First, the total word count only reached 1,250 to 1,450 words. Still short. Second, the second prompt kept repeating the article title at the top of its output, even when I told it not to. Every single time. It was one of those things that seemed easy to fix with a clearer instruction, and then kept happening anyway.
Two-pass generation was clearly the right direction. But prompting alone was not going to solve everything.
This was the turning point, and it came from accepting something uncomfortable: some problems are easier to fix with code than with words.
The internal linking issue was a good example. Asking the model to place links naturally and distribute them across the article produced inconsistent results. Sometimes it worked. Sometimes all four links landed in the same paragraph. Trying to write a prompt that reliably fixed this was a diminishing returns exercise.
So instead, I introduced ALL CAPS placeholders inside the generated content. The model would write something like “working with a NYC EVENT PRODUCTION team means…” and a post-processing script would replace that placeholder with the actual hyperlink after generation. Clean output during writing, correct links in the final version.
The duplicate title problem got solved the same way. A function scanned the combined output for any repeated H1 and removed it automatically. Two lines of code that worked every time, compared to prompt instructions that worked most of the time.
The final version of the system pulled everything together. Two-pass GPT-4o generation with lower temperature for consistency, maximum token allowance to reduce early stopping, strict paragraph length instructions, the duplicate title remover, and the link post-processing step.
Here is what stable output looked like:

The one thing that did not get solved was the word count target. The original goal was 1,950 to 2,100 words. The system never reliably got there. After a while, I stopped trying to force it and started asking a different question: is a consistent 1,380-word post that ships every time actually worse than a 2,000-word post that requires constant intervention?
For this workflow, the answer was no. The shorter, cleaner draft was more useful.
Compared to the manual baseline, the impact was significant across every metric that mattered.

The word count shortfall meant each post needed a bit more from the human editor to expand key sections. But that tradeoff was worth it given everything else the system got right.
If you are building something similar, these are the failure modes worth knowing about before you hit them yourself.
Word count collapse. Single-pass prompts consistently fell short. The model does not run out of knowledge, it just loses structural discipline over long outputs. Two-pass generation is the practical minimum for anything over 1,200 words.
Link clustering. Left to itself, the model tends to place multiple links close together or in a single section. Post-processing is far more reliable than prompt instructions for solving this.
Title duplication. The second prompt often repeated the article title even with explicit instructions to skip it. A simple programmatic check fixed this permanently.
Paragraph bloat. Explanation-heavy sections regularly ballooned past 140 words. Explicit limits help, but a human pass is still the most reliable way to catch this.
The system did not produce the perfect 2,000-word automated blog post I originally planned for. What it produced was something more practical: a dependable, brand-consistent draft that is ready for a light human edit in under 10 minutes, at a cost that makes weekly publishing genuinely viable for any business.
The biggest mindset shift was treating the human editor as part of the system rather than as evidence that the system failed. The AI handles the structural heavy lifting. The editor catches what slipped through. Together, they produce something neither would get to as quickly alone.
If you are trying to build the same thing, start with two-pass generation, move formatting fixes into post-processing early, and pick a word count you can hit consistently rather than one you can hit occasionally.
This kind of workflow thinking sits at the intersection of content operations and SEO. If you are trying to build something similar for your agency or business, or if you just want to talk through what a content system could look like for your specific situation, I am happy to get into it.
Dhruv is an SEO consultant working with agencies, founders, and business owners. 500+ projects. 6+ years. No fluff.
Ready to grow? Pick the way that works for you.