Step 1: Structure clusters around jobs-to-be-done keywords
The fastest way to build topical authority on a weak domain is to stop thinking in “keywords” and start thinking in the job the buyer is trying to get done. JTBD clusters force you to cover the full decision journey, which is exactly what Google rewards when it evaluates topical depth and intent coverage.
Here’s the cluster structure we use for early-stage SaaS when we have to win on relevance before we can win on links:
| JTBD stage | What the searcher is doing | SERP intent pattern | Content type that wins |
|---|
| Problem recognition | Naming the pain, symptoms, risks | Guides, checklists, definitions | “What is…”, “How to fix…”, “Signs you need…” |
| Evaluation | Comparing approaches and tools | Comparisons, templates, buyer guides | “X vs Y”, “best tools for…”, “alternatives” |
| Implementation | Setting up, integrating, measuring | Tutorials, SOPs, playbooks | “How to… step-by-step”, “setup guide”, “framework” |
| Proof and purchase | Validating ROI, de-risking | Case studies, pricing pages, demo pages | “ROI”, “case study”, “pricing”, “demo” |
When you do web research for a cluster, don’t just scrape keyword volume. Open the top 5 results and write down what they all have in common: sections, examples, tools mentioned, and what they avoid. That’s your baseline for search intent. Google Search Central’s guide on how search works is still the cleanest explanation of why intent matching beats clever copy.
A practical way to pick your first cluster on a low-DR site is to start with a pain you solve that also has implementation complexity. Those SERPs are often less dominated by giant publishers because they require real operational detail.
Quick note on “DR in SEO”: teams obsess over it, but you can still rank with low authority if you choose intent-smart topics and build internal link structure. DR is a third-party metric popularized by Ahrefs, not a Google metric. It’s directionally useful, not a scoreboard.
If you’re using Surfer SEO (or any content optimizer), treat it like a coverage checklist, not a writing prompt. The goal is to satisfy intent and demonstrate expertise, not to hit an arbitrary term frequency.
Step 2: Content calendar examples for SaaS SEO (a 4-week sprint)
The calendar below is built for an early-stage SaaS team that can ship 2 posts per week plus one lighter update. It’s designed to create one clear topical footprint quickly, then reinforce it with internal links and refreshes.
Example sprint theme: “Reducing manual reporting time” (swap for your product’s core job).
| Week | Publish | Primary goal | Conversion path |
|---|
| Week 1 | Pillar: “How to reduce manual reporting time (framework + benchmarks)” | Own the main informational intent | Soft CTA to demo + link to 2 supporting posts |
| Week 1 | Support: “Manual reporting vs automated reporting: what breaks at scale” | Evaluation intent | Link to pillar + product page for automation feature |
| Week 2 | Support: “Reporting workflow template (downloadable)” | Capture demand + email | Template gate or signup, plus link to pillar |
| Week 2 | Support: “Best tools for automated reporting for [role]” |
Two execution details matter more than the calendar itself:
First, publish the pillar early. A pillar is not “long content.” It’s the page you want other pages to cite internally. If you wait until week 4, you waste internal link equity.
Second, schedule refresh work as a first-class task. We’ve seen early SaaS teams get their first meaningful traffic lift by updating 5 existing posts that were stuck in positions 11-20. Those are your quickest wins because Google already understands the page and just needs stronger intent alignment, internal links, and clearer topical coverage. VellumUp’s breakdown of why great content still doesn’t rank matches what we see most often: the page is “good,” but it’s not the best answer for that query.
If you’re unsure about cadence, don’t chase a mythical best time to post. Consistency beats timing for SEO. This is exactly why we like sprint-based calendars that you can actually maintain, then automate. VellumUp’s view on cadence vs quality for SEO publishing is the same operational truth: missed weeks cost more than slightly imperfect drafts.
Step 3: Balance product-led pages vs informational posts (without cannibalization)
The trap for product-led SaaS teams is swinging too far in either direction:
If you publish only product-led pages, you’ll struggle to rank because you’re targeting bottom-funnel queries your domain can’t yet win, and your pages often don’t match informational intent.
If you publish only informational posts, you’ll get traffic that never converts, and you’ll train Google to see you as a publisher, not a solution.
The balance that works on low authority is: 1 product-led page for every 3-4 informational posts, but only when the product-led page is mapped to a query that actually wants a product page.
Use this intent filter before you create a product-led page:
| Query pattern | What Google usually wants | What you should publish |
|---|
| “best [tool] for…” | Lists, comparisons | Informational post + comparison block + internal link to product |
| “[tool] pricing” | Pricing pages | Product-led pricing page (and make it indexable) |
| “[tool] demo” | Demo/landing pages | Product-led demo page with clear next step |
| “how to [do task]” | Tutorials | Informational tutorial with product as optional accelerator |
This is where a lot of “SEO in web development” decisions show up. If your dev team blocks important pages behind scripts, noindex tags, or gated flows, your product-led pages never become eligible to rank. Google’s own documentation on SEO basics is blunt: if it can’t be crawled and understood, it can’t rank.
One more thing: avoid keyword cannibalization by assigning exactly one “primary” URL per intent. If two posts both target “automated reporting tools,” pick one as the canonical target and rewrite the other to a different angle (industry, role, integration, or use case).
Step 4: Plan internal links to demos and signups (programmatic, not random)
Internal linking is where early-stage SaaS sites can “manufacture” authority flow without begging for backlinks. But it only works if you treat it like architecture, not decoration.
Define three destination types:
- Pillar hubs (informational, indexable, broad intent)
- Feature or integration pages (product-led, mid-funnel)
- Demo/signup pages (conversion endpoints)
Then apply a repeatable rule set to every new post. Here’s the simple version we use:
| From page | Link to | Anchor style | Why it works |
|---|
| Support post | Pillar hub | Descriptive, non-branded | Reinforces topical cluster and helps the hub rank |
| Support post | 1 feature/integration page | “how to [do job] with…” | Bridges informational intent to product capability |
| Support post | Demo/signup | Action-oriented but specific | Converts without stuffing “demo” everywhere |
| Pillar hub | All supports | “Read next” style blocks |
If you want to be more aggressive, add programmatic internal linking blocks. Example: every integration tutorial automatically links to (a) the integration page, (b) the “how to choose” comparison post, and (c) the demo page. That’s not a gimmick. It’s how you keep link patterns consistent as you scale to 50+ posts.
A common failure mode is burying conversion links in generic CTAs. Don’t. Put one clear conversion path per page, matched to intent. A tutorial should push “try it on your data” (demo). A template post can push signup. A comparison post can push “see how we compare” then demo.
Step 5: Automate scheduling and publishing without breaking your brand voice
A content calendar is only valuable if it ships. Early-stage teams lose months to “drafts in docs,” inconsistent formatting, and manual copy-paste publishing that introduces errors and delays indexing.
The operational fix is straightforward: separate strategy from execution, then automate execution.
Strategy is: cluster map, sprint calendar, internal link rules, conversion paths, and update schedule.
Execution is: research, writing, images, formatting, publishing, and indexing checks.
If you automate execution, you still need quality control. The minimum QA we run after auto-publishing is: confirm the canonical URL, ensure the page is indexable, validate internal links render as crawlable HTML, and request indexing for priority pages in Search Console.
If your team struggles with “robotic” output, don’t accept it as the cost of automation. Brand voice can be learned and enforced. VellumUp’s guide to fixing robotic AI blog posts with brand voice matching covers the exact failure modes that make content feel generic, and the inputs that actually fix it.
For teams deciding where to publish, your CMS matters less than your workflow, but it still affects speed and technical control. If you’re weighing platforms, VellumUp’s breakdown of what differs between Wix SEO and WordPress SEO is a practical lens on where teams get stuck.
Frequently Asked Questions
What is the difference between deep research and web research?
Web research is collecting what’s already published: SERP results, competitor pages, forums, and documentation. Deep research adds synthesis: extracting patterns, testing claims, and adding original examples or benchmarks so your page is meaningfully better than what already ranks.
How to do web research for beginners?
Start by opening the top results for your query and writing down repeated subtopics and missing angles. Then validate with one primary source (official docs, reputable studies) and one practitioner source (credible blogs or case studies) before you outline your post.
What does DR stand for in SEO?
DR stands for Domain Rating, a backlink authority metric from Ahrefs. It’s useful for rough competitive analysis, but it’s not used by Google, and it shouldn’t decide your content plan by itself.
What is DR and PR in SEO?
DR is Ahrefs’ Domain Rating. PR usually refers to Google PageRank historically, which was a link-based algorithm component; Google no longer exposes public PageRank scores, but links still matter.
Next step: build your first sprint calendar in 30 minutes
Pick one JTBD your product solves, then draft a 4-week sprint with one pillar and 6 supporting posts that match problem, evaluation, and implementation intent. Add one internal linking rule (support posts must link to the pillar and one demo path), then publish on a schedule you can sustain for 8 weeks.
If you want the execution side handled end-to-end, connect your site and let VellumUp research topics, write in your learned brand voice, schedule, and auto-publish to WordPress, Shopify, Webflow, Wix, or a webhook via VellumUp publishing integrations. Your next sprint can be planned today and live this month: create a VellumUp account.
VellumUp10 min read
