B2B Service-Page and Resource-Centre Planning: A Before-and-After Example
Give every page one primary job. Service pages help buyers evaluate an offering; resource pages help them understand, diagnose or compare. This guide shows how to map overlaps, decide what to merge or split, connect the right pages, and verify the change without assuming every keyword needs its own URL.
Start with page roles, not a list of keywords
B2B service-page planning is a content-architecture problem before it is a writing problem. The useful question is not “How many pages can we create?” but “What distinct job does each page need to do for a prospective customer?”
In this guide, a service page is a commercial page that helps someone evaluate a specific offering. A resource page is an educational or decision-support page that helps someone understand a problem, compare approaches, prepare for a project, or judge whether a service is relevant. A resource centre is simply an organised way of making those useful resources findable; it does not need to become a large publishing programme or a separate page for every search variation.
| Page type | Primary reader job | Typical content | Useful next step |
|---|---|---|---|
| Service page | Evaluate whether this provider and service fit the need | Who it is for, scope, process, constraints, proof, deliverables, next step | Enquire, book, request a proposal, or review relevant proof |
| Resource page | Understand, diagnose, compare, or prepare | Explanation, decision criteria, checklist, example, trade-offs, implementation guidance | Continue to a related resource or relevant service page when appropriate |
| Case study | Assess evidence and fit | Context, challenge, work performed, limitations, outcome evidence | Review the related service or contact the provider |
| Hub or resource index | Find the right supporting material | Curated links grouped by real user need | Choose the most relevant guide, case study, or service |
Decide which topics deserve separate URLs
A separate page should earn its place by serving a meaningfully different task, audience, offer, or decision. Two phrases that use different wording do not automatically require two pages. Conversely, two services that share vocabulary may still deserve separate pages if the deliverables, buyers, proof requirements, or next actions are genuinely different.
Before approving a new page, write down five things: the primary audience, the problem they are trying to solve, the page's main job, the evidence or detail that will make the page distinct, and the action a reader should be able to take next. If you cannot make those answers materially different from an existing page, the stronger move is often to improve the existing page instead of creating another URL.
What current Google guidance actually supports
Google's SEO Starter Guide says logical site organisation can help users and search engines understand how pages relate, while also cautioning site owners not to reorganise everything merely for SEO. Google also recommends people-first content and says important pages should be reachable through crawlable links. Those principles support clear page roles and useful connections; they do not create a requirement for a particular B2B “topic cluster” model or a fixed number of pages. See Google's SEO Starter Guide and people-first content guidance.
That distinction matters. Your content plan should describe the business and customer journey accurately first; search optimisation should make those useful pages easier to discover and understand, not manufacture additional pages that have no independent purpose.
Audit the current structure before adding content
Start with an inventory of the service and resource URLs that already exist. A spreadsheet is enough. For each URL, record its page type, intended audience, primary user task, main service or subject, current internal links, and a proposed action: keep, improve, merge, split, redirect, or retire.
Then work through the following checks:
- Page-role clarity: Can you explain in one sentence why this page exists and what the reader should be able to do after using it?
- Intent overlap: Are two or more URLs trying to satisfy essentially the same commercial or informational need? If so, compare what is genuinely unique before deciding to keep both. Our guide to search-intent mismatch gives a deeper framework for this step.
- Offer differentiation: If two service pages are separate, do the scope, deliverables, audience, proof, process, or conversion action differ enough to justify that separation?
- Resource usefulness: Does each guide, checklist, comparison, or case study answer a real follow-up question, or is it mainly a thinner restatement of a service page?
- Internal discovery: Can important pages be reached through normal crawlable links from other findable pages, and does the link text explain the destination? Google's link best-practices documentation recommends descriptive anchor text and says every page you care about should have a link from at least one other page.
- Technical conflicts: Check that important pages are not accidentally blocked, redirected through unnecessary chains, canonicalised to the wrong URL, or left as orphan pages after restructuring.
Do not use a canonical tag to solve a content-planning problem. Canonicals are useful signals for duplicate or very similar URLs, but they are not a substitute for deciding whether two pages should both exist. If two service pages are genuinely redundant and one should replace the other, consolidating useful material and redirecting the retired URL is usually clearer than keeping two competing pages and simply pointing one canonical at the other. Google's current canonicalisation guidance describes redirects and rel="canonical" as different signals and notes that specifying a canonical preference is not always required.
Build the page map, then decide what to keep, merge or split
A useful content map is small enough to make decisions from. For each planned page, record the working URL, page role, primary audience, main task, unique evidence or detail, supporting resources, inbound link sources, outbound contextual links, conversion action, and owner. This turns “we need better content architecture” into a set of specific editorial and technical actions.
| Decision | Use it when | Avoid it when |
|---|---|---|
| Keep and improve | The URL already has a clear purpose but needs stronger coverage, proof, or internal links | You are only keeping it because it already exists |
| Merge | Two pages serve the same user task and neither has a defensible separate role | The services or audiences are genuinely different |
| Split | One page is trying to serve distinct services or audiences that need substantially different detail and actions | You are splitting synonyms or minor keyword variants |
| Create a resource | A recurring customer question deserves a standalone answer that would still be useful without a sales pitch | The resource would simply paraphrase the service page |
| Retire and redirect | An old URL has a clear replacement and should no longer remain a separate page | There is no genuinely equivalent destination |
Do not rename URLs just to make the map look tidier
Descriptive URLs are useful, but an existing, working URL does not need to be changed merely because a neater slug is available. A URL change creates migration work and can cause temporary Search fluctuations while the new location is recrawled and reprocessed. If a URL genuinely must change, map the old URL to the closest replacement and use a permanent server-side redirect such as 301 or 308. Google recommends permanent server-side redirects when a page has permanently moved; its redirect guidance explains the options.
For a broader look at hierarchy and discoverability, see ScanMySEO's site-structure guide.
Link pages where the next step is genuinely useful
Internal linking should follow the reader's decision path, not a quota. A service page can link to a comparison, implementation guide, or case study when that resource helps answer a likely objection or next question. A resource can link back to a service when the reader has reached the point where professional help is relevant. Use descriptive anchor text rather than generic labels such as “read more”.
Do not force every resource to link to every service, and do not build a dense web of keyword-heavy links simply to signal relationships. Google says there is no magical ideal number of links on a page. The practical standard is simpler: important pages should be discoverable, and each contextual link should help a reader understand where they are going.
Planning for AI search does not require a second architecture. Google's current generative-AI Search guidance says foundational SEO still applies and advises against creating separate pages for every conceivable query variation. For a B2B site, model distinct customer needs and offerings rather than producing near-duplicate pages for synonyms or prompt variants. See Google's guidance for generative AI features in Search.
Verify the implementation first, then measure performance
Do not define success as “rankings went up after we changed the architecture.” Search performance can move for many reasons, and Google does not guarantee that a particular content or structural change will produce a visible ranking improvement. Verification is more useful when it is split into two layers.
Before-and-after example: a managed IT services site
Imagine a small managed service provider with several overlapping pages. The example below is hypothetical; the URLs are illustrative.
Before:
| URL | Current role | Planning problem |
|---|---|---|
/it-support | General service page | Broad overview with no clear distinction from the other IT support pages |
/managed-it-support | General service page | Covers the same audience, offer, and conversion action as /it-support |
/business-it-support | General service page | Mostly repeats the same service using another phrase |
/resources/it-support | Educational page | Restates the service description instead of answering a distinct research question |
The first decision is not which keyword belongs to which URL. It is whether the business actually offers several distinct services. In this example, assume all three service URLs describe the same managed IT support package for the same type of buyer.
After:
| URL or role | Decision | What changes |
|---|---|---|
/managed-it-support | Keep as the primary service page | Combine the strongest useful material from the overlapping pages; make scope, process, limitations, proof, and next step explicit |
/it-support and /business-it-support | Retire if they are genuinely redundant | Redirect permanently to the retained equivalent after checking there is no distinct intent or audience being lost |
/resources/how-to-choose-managed-it-support | Create only if the research task is real | Answer evaluation questions such as coverage, response model, contract scope, onboarding, security responsibilities, and comparison criteria; link to the service page where relevant |
| Relevant case study | Keep as evidence | Link from the service page near the claim it helps substantiate, rather than hiding it in a generic resource list |
If /it-support were already the strongest, clearest, established URL, there would be no SEO rule requiring you to rename it to /managed-it-support. The goal is a clear page model, not prettier slugs.
Use two verification layers
1. Implementation verification. Crawl the changed area and confirm that retained pages return the expected successful response, retired URLs redirect to the intended destination, internal links point directly to final URLs, important pages are not orphaned, and canonical or indexing directives were not changed accidentally. For priority URLs, Google's URL Inspection tool can help confirm what Google knows about a page.
2. Performance verification. Capture a baseline before the change, then review the affected URLs and queries in Search Console rather than judging the whole site at once. Track clicks, impressions and click-through rate, and use your analytics or CRM to check whether relevant leads or enquiries improved. Google's Search Console Performance report supports page- and query-level analysis; remember that some query data is anonymised or omitted, so it is not a complete keyword ledger.
Choose a comparison period that makes sense for your traffic volume and seasonality. Do not treat a fixed four- or six-week window as a universal rule. Google notes that some changes can show effects in days while others can take months, and recommends looking at patterns in affected pages and queries before making radical changes.
The practical finish line is not “we created a resource centre.” It is that each important page has a defensible role, overlapping pages have been deliberately resolved, useful supporting content is connected at the point of need, and the technical implementation can be verified without guesswork.