Slice Research: Decompose a Big Product Into One-Feature Sites

1. Why I'm writing this

I'm Hugozen. My SEO flagship covered keyword picking, indexing and GEO. This post goes one layer down: how to slice once you've picked a direction.

My habit is to look at a big product and ask whether it can be taken apart. A big product usually packs a dozen features, and each one has people searching for it. One feature becomes one small site, which ships fast and is cheap to test. But I've been burned by guessing that a slice "should have volume" and finding out after building that nobody searches for it. So I now run "check before you build": every slice gets an evidence table first, and then I decide.

This post covers the process and the judgment calls. It doesn't name specific keywords, products or sites. That's deliberate: a named keyword becomes someone else's ready answer and goes stale. The process is the part that reuses.

2. The slicing process

1. Split. List the product's features one by one, each in a sentence a user would actually say. No filtering at this step; finer is better.

2. Pull data. For each slice I pull five things only:

• Monthly search volume (relative size matters, not the absolute number)
• KD (keyword difficulty)
• CPC (whether anyone pays for this term)
• Trend (rising, flat, or a short-lived spike)
• The size of the identifiable sites on the SERP (big sites, mid-size sites, or a pile of small ones)

The repetitive pulling goes to a worker on my home machine, which produces a table. The coordinator bot only checks that the table is complete and has no obvious errors. It doesn't draw conclusions for me.

3. Evidence first, judgment second. The table holds facts, not "recommended to build". The "build or not" column is mine to fill. Bots easily turn "there's data" into "worth doing", and those aren't the same thing.

4. Four outcomes. Each slice ends up in one of four places: a new site; merged into an existing similar site (for a family of similar tools, merging into the existing site beats buying another domain, and the authority stays in one place); a roundup post to test the waters; or dropped.

3. Two counterintuitive cases

Case one: "directory-style" terms can have tiny volume in the US. I used to assume these were big because such sites look common. After checking, US search volume was much smaller. The real volume sat in the "tool-style" slices under the same big product: users have a clear input and output, and their search intent is specific. The lesson: the type of site and the volume of the keyword are different things. When a category looks busy, I check the keywords first, not the number of sites.

Case two: a bookmark-heavy hit means users want a curated list. Some things get a high ratio of saves to likes. That tells me people want to keep it and use it slowly, not read it once. This kind of demand suits a roundup post first: cheap, quick feedback. If the feedback is good, I turn the entries into on-site pages. Don't reverse the order: building the site first and filling it later often produces an empty shell nobody wants.

One more direction lives only in my idea list: if the internal tools of some kind of Agent product become public, they might be turned into programmatic pages. It's untested, so I don't treat it as a conclusion.

4. Pitfalls

1. Scraped ranking sites that come back as zero rows. bot protection may simply be blocking the scrape; it doesn't mean there's no data. When I see a blank, I suspect the scrape before I suspect the demand.

2. Treating big volume as worth building. Big volume with a first page full of big sites leaves a new site no opening. The reverse is a signal: modest volume with a first page of small sites.

3. Researching and then stalling. My weakest link has consistently been customer acquisition. Slice research helps me choose better keywords, but even after choosing well, someone still has to do the backlinks and promotion. I saw the same gap when comparing myself with 哥飞's "20 Pieces of Advice for Indie Developers" (《给独立开发者的20条建议》): promoting, scaling up and fully exploiting one keyword are my weak spots.

4. Slicing too many at once. A big product can split into twenty or thirty slices, and building them all isn't realistic. The evidence table is for ranking, not for building everything.

5. Checklist

1. Pick a big product and split its features into a slice list that fits on one page.
2. Fill five columns for each slice: volume, KD, CPC, trend, SERP site size.
3. When a scrape returns zero, check whether it was blocked before concluding anything.
4. Fill in "build or not" yourself; don't let a bot do it.
5. For similar slices, check whether they can merge into an existing site before buying a new domain.
6. When you see a bookmark-heavy hit, write a roundup post first, then turn it into on-site pages.
7. For a category that looks hot, check the keywords before looking at the sites.
8. Plan acquisition right after launch; don't wait until the build is done.

6. Back to the flagship

The basics of keyword picking, indexing and GEO are in this post: SEO flagship. Slice research is the next layer down, and the two read better together.

I'll keep posting through RSS. There are three lines under /posts for now: Agent collaboration, SEO & going global, and monetization.