A keyword sheet tells you what people type. It does not tell you how many pages you need, what goes on each one, or which ones you should not build at all. That gap is where most B2B sites lose time: 500 rows become 500 thin pages that all say the same thing, or 500 rows become one page that answers none of them.
This is the process for turning the sheet into a small number of pages that can actually ship — model pages (one part number, one page) and application pages (one use case, one page).
Step 1: Give the sheet the columns it actually needs
Most sheets have one column: keyword, maybe volume. Add these before anything else.
The two columns that do the most work are intent and notes. Notes is where you write the question in plain words: "replaces XYZ-120" actually means can I substitute this part without redesigning the board. That sentence becomes the first paragraph of the page. If you can't write it, you don't yet know what the page is for.
Step 2: Sort every row into one of five intents
IntentQuery looks likePage typeIs it a landing page?Model lookup"XYZ-120 datasheet", "XYZ-120 price"Model pageYesCross-reference / replacement"replacement for ABC-45", "ABC-45 equivalent"Cross-reference page, or a block on the model pageYes, if there is enough to sayApplication / industry"MOSFET for 48V motor drive", "pumps for food processing"Application pageYesSpecification / problem"why does X overheat at 20kHz"Technical note, linked from bothUsually noComparison / category"X vs Y", "types of Z"Category or comparison pageSometimes
The mapping matters more than the count. A model lookup and an application search come from different people at different stages: one has a part number in a spreadsheet, the other has a problem and no part number. Different reader, different page.
Step 3: One cluster = one page
A cluster is a set of rows that the same page would answer. The test: if you wrote the answer to row A, would row B need a different answer? If not, they're the same page.
Two rules that save rework:
- Don't split variants across pages unless the specifications actually differ. Three variants with identical specs are one page with one table.
- Don't merge a model page into an application page, or the reverse. The model page answers "what are the specs of this thing"; the application page answers "what do I need for this job". Combining them produces a page that ranks for neither.
Step 4: Run the go/no-go test before adding a page to the plan
A page has to pass all three:
- Can you write 250–400 words about this specific item without repeating the paragraph next door?
- Is there at least one piece of first-hand material — a spec table, a drawing, a test condition, an application note, a photo of the actual part?
- Can you name three questions buyers ask about it, taken from emails, quotes or support tickets?
Two out of three is a no. Merge instead: the model into its series page, the application into the industry page. A page that fails this test will be a template with the name swapped, and buyers can tell.
Step 5: The model page, block by block
BlockContentH1 and title tagThe exact model string plus what it is. Not "Welcome to our product page"Answer paragraphWhat it is, what it's for, and the one spec that usually decides the saleSpec tableThe parameters buyers filter on — in a real table, never an imageCross-referenceWhat it replaces, and what it does not replaceDocumentsDatasheet, drawing, certificate — file names contain the model, not "scan001"OrderingMOQ, lead time, sample policy, how to request a quoteFAQThree to five questions copied from real emails, answered in two sentencesCTAOne action, repeated at the top and the bottom
The cross-reference block is the one people skip, and it is the one buyers trust most. "No verified equivalent for this part" is a legitimate answer. A forced match that fails in the customer's application costs far more than the lost click.
Keep the CTA to one thing. "Contact us / download / chat / subscribe" is four decisions and usually produces none.
Step 6: The application page, block by block
Different reader, different order:
- H1 — the application as the buyer says it, not your internal category name.
- The problem — two or three sentences describing the conditions and what typically fails.
- Selection criteria — a table of what matters in that application: temperature, load, duty cycle, ingress protection, cycle life, whatever applies, with a "why it matters" column filled in.
- Which families fit — links to three to six model pages, each with one line on why it is listed.
- A worked example — a real configuration with the numbers, if you can publish them.
- Getting started — what you need from the buyer (drawings, quantities, target price, timeline) and what happens after they send it.
- FAQ — same rules as the model page.
Application pages do the internal linking job nothing else can: they are the only entry point for someone who doesn't know your part numbers yet.
Step 7: Linking and URL rules
- URL: short, lowercase, no dates, no session parameters, category then item. Decide once — changing it later means redirects forever.
- Every model page gets at least one link from an application page and one from its series page.
- Every application page links to at least three model pages and back to the category.
- Anchor text is the model number or the application name. Never "click here" or "learn more".
- Breadcrumbs on both page types.
- No orphans. Before launch, list pages with zero internal inbound links and fix them.
Step 8: Pre-publish checklist
- [ ] H1 differs from the title tag; the target phrase appears once in each
- [ ] The first paragraph answers the query without scrolling
- [ ] Specifications in a real table, not an image
- [ ] Cross-reference block states what does not match
- [ ] At least three FAQ entries taken from real questions
- [ ] One CTA, top and bottom
- [ ] Form tested end to end — submit it, then confirm the message arrives in a mailbox someone reads
- [ ] Spec table readable on a 360px screen
- [ ] Every link on the page resolves
- [ ] Page included in the sitemap, nothing blocking it
- [ ] Internal links in and out
- [ ] Form submit tracked, so you can tell later whether the page did anything
Step 9: What to do after it is live
Wait four to eight weeks before judging a page. Then look at the queries it actually received:
- Ranks for the planned keyword → leave the page alone; add internal links to it.
- Ranks for a related but different query → either retitle to match reality, or split a new page if the query needs a genuinely different answer.
- Impressions but no clicks → fix the title and description, not the body.
- No impressions at all → check indexing first, then internal links. A page with no inbound links was effectively not published.
Don't rewrite a page every fortnight; you will never learn which change did anything.
The mistake that costs the most
Generating one page per row. A spreadsheet column can produce 500 pages in an afternoon; what it cannot produce is 500 unique spec tables and 500 answers. Ten model pages and four application pages — each with something only you can say — will outperform a thousand templated ones, and they are the ones you can still maintain a year from now.#marketing #seo #webdev #software #coding #development #engineering #inclusive #community
From a B2B keyword sheet to a live landing page: model pages and application pages, step by step
