B2B Website Strategy

B2B Website Technology Selection & SEO

Whether diagnosing an existing site or planning a new one, the goal is to find the best solution under the client's current constraints—not to declare a single "optimal technology" or "best SEO" that works for every factory.

Explanations are in plain language for less technical audiences: conclusions first, jargon explained in simple terms with industry-specific examples on first use. When the client says "I don't know," provide accessible options rather than asking them to decide on SSR, databases, or frameworks upfront. If the client already has a platform preference, optimize within that constraint; only suggest alternatives if a specific conflict is identified.

For broader explanations, refer to the companion eight layers, 32 knowledge groups and interactive knowledge graph. The "eight layers" refer to eight business and technology selection dimensions; the binary tree is a knowledge classification for flexible combination, not a mandatory decision path. Only consult relevant entries when needed—no need to load the entire map.

1. Choose Your Entry Point

A｜Existing Site Audit. When a user provides their own website for analysis, redesign, or benchmarking, first read the Site & Competitor Audit, actually visit the site and key competitors, and deliver an evidence-based assessment of the current state, gaps, and recommended technology selections. Reuse any existing business information; only ask a few additional questions that could affect audit scope or recommendations—do not make the client fill out a full new-site questionnaire. If the client provides insufficient competitors, search for candidates based on product, buyer, and market context, and explain the selection rationale.

B｜New Site Planning. When the user has no existing site or explicitly wants a new site plan, use the interview below to deliver a technology and SEO plan based on their answers. A user providing a reference URL does not automatically mean they want an audit. If they have an existing site but also want to rebuild, first complete path A for a current-state audit, then supplement with constraints from path B to compare keeping, partial refactoring, or migration.

Path A must not present the skill's pre-written plans as actual audit results; path B must not treat teaching examples as client facts. Both paths must deliver specific CDN configurations and other applicable supporting items.

2. Minimal Interview, Reuse Known Answers

Start by filling in answers from the current conversation, client files, and authorized project documents to avoid repetitive questions. Do not infer actual client facts from teaching examples. For a new ordinary client, limit the initial interview to the following seven core groups—at most three questions per round. Usually start with questions 1–3, then only ask for missing items that would change the conclusion. The user may provide all answers at once.

1. What do you sell and to whom? Main products, customer type, manufacturer/trader role, and the most compelling genuine advantage. E.g., "Hotel chairs, sold to procurement managers, can customize fabric."
2. Which markets first? Priority countries, languages, and whether anyone can review translations. Distinguish "German customers" from "German content"; do not assume one country equals one site.
3. How do buyers close the deal? Do they inquire after viewing materials, or log in to see negotiated prices and place orders online? What information is needed in an inquiry? Reuse existing business email, customer service/chat, and CRM data; ask about key requirements like service hours, attachments, or configurators only when needed.
4. How much content is there and who updates it? Approximate number of products, categories, articles; update frequency; editors' technical ability; existing images, specs, case studies. Approximate counts (few / hundreds / tens of thousands) are sufficient; no need to inventory to the unit.
5. New site or redesign? Existing URL/system, current search traffic and inquiries, domain and account control, available Search Console/analytics/keyword data. For redesigns, understand important old URLs and business dependencies.
6. Budget and timeline? Approximate build cost, target launch date, ongoing monthly maintenance investment and who is responsible. Separate build budget from ongoing SEO content budget and ad budget.
7. Must-have requirements? Platform preferences, exportable source code/data, special deployment or data requirements, customer accounts, quote builders, integration with existing systems. Skip if no special requirements.

Do not mechanically ask all seven questions before working. If the direction is clear, provide it immediately; only continue asking if an unanswered condition could reverse the proposed solution. If the user wants a direct plan or demo, list necessary assumptions and proceed—do not fabricate client answers. If the client cannot answer some questions, deliver a provisional plan and highlight the most impactful gaps.

3. Make Eight-Layer Technology Decisions

Follow the Selection Guide & Eight-Layer Template to compare routes. Generally, provide one primary solution and one most competitive alternative, clearly stating the selection criteria, trade-offs, and what changes would make the alternative more suitable. Do not present a flat tool list or create false precision with unjustified scores.

The eight layers are: ① Business & Build Route; ② Content & Data; ③ Front-end & Interaction; ④ Rendering & Caching; ⑤ Deployment & Performance; ⑥ SEO & Multilingual; ⑦ Inquiry & Attribution; ⑧ Security & Maintenance.

For each layer, provide: "What to choose—Why—Client scenario—Dependencies/Costs." Also verify the entire combination works: Does the runtime environment support the chosen framework's ISR? Does WordPress need PHP/database? Who handles content updates and invalidation notifications?

Key boundaries:

• CMS/SaaS is about content or hosting capability; Headless is a front-end/back-end separation architecture; framework is a development tool; SSR etc. are rendering strategies; CDN is a delivery infrastructure. They are not on the same layer.
• Do not set WordPress as the default winner. Editorial workflows and standard inquiries may suit it; small content sets with developer maintenance may suit static solutions; complex accounts/configurators may suit application frameworks; standard transactions may be better served by e-commerce platforms.
• When a client mentions AI site building, distinguish between initial code/page generation and ongoing operational costs. AI can assist WordPress custom themes, visual tools, and framework development; do not automatically conclude Next.js is better or that the existing site must be migrated. Code/component reuse is normal engineering—check whether different products need appropriate content fields and procurement processes rather than just pursuing different per-page appearances.
• Static content does not force SSG; needing a form does not force full-site SSR; using React on the front end does not mean the whole site is CSR.
• Choose rendering per page or section. Clarify when the first version is generated, how cache hits/misses are handled, how published content is refreshed, and how private data is isolated. WordPress full-page caching and ISR behavior may be similar, but do not equate them directly; ISR is not necessarily a scheduled task.
• Do not present hosting prices, plugin capabilities, plan limits, or framework deployment support from memory. Verify against vendor official documentation, record the source and date. When unable to verify, use "candidate" or "to be verified" descriptions—do not fabricate quotes.
• Choose CDN and origin separately. WordPress still requires a hosting environment that runs PHP/database; using a CDN does not force the origin to be in Europe, nor does it automatically eliminate the impact of origin distance. Compare regions based on cache hits, misses, dynamic requests, and the location of primary buyers and maintainers; do not treat the previous example's European server as a hard requirement. Do not repurchase facilities already included in the hosting plan.

4. Specify Plugins, Services, and Configuration

Read the Plugins, Email & Services Guide and deliver a specific configuration checklist based on the chosen platform. Must cover: inquiry storage, site email sending, business email and replies, live chat (if needed), SEO/multilingual, caching/CDN, backups, and analytics. For each item, state: required capabilities or optional enhancements, candidate/selected tools, rationale, key configuration, account ownership, payment boundaries, verification/validation status.

If the client mentions a specific product like Tidio, include it in the comparison and plan—not just "add live chat." Similarly, email configuration cannot be simplified to "install SMTP plugin": clearly separate the roles of the business inbox, the site's SMTP/API outgoing channel, and domain verification. Explicitly defer capabilities not needed in this phase; do not duplicate functions already covered by native or hosting capabilities.

Every plan must include a dedicated CDN Selection, Setup & Cache Configuration Table, read from the CDN Plan Specification. Specify provider/plan, origin and access domains, DNS/proxy or resource domain setup, TLS, exact match conditions, edge/browser cache times, bypass conditions, cache key, rule order, purge-on-publish, fallback, and verification. "Use Cloudflare/CDN" alone is not acceptable; if using a hosting-provided CDN, still describe the controllable scope. If no additional CDN is enabled, explain why and who handles delivery—never leave it blank.

5. Generate SEO & Inquiry Plans with Evidence

Follow the SEO Plan & Evidence Specification. First distinguish between client facts, actual research, and hypotheses to be verified; then determine which buying needs should be addressed by category pages, product pages, application pages, or articles.

When online search is possible, cross-check relevant Google official guidelines and supplier capabilities, and perform decision-appropriate research on a few key buying needs and the client's provided competitors. Record the target country/language and the actual research scope; do not claim precise SERP results for a specific region without verification, or claim to have viewed pages not opened. When no existing site or keyword set is available, still deliver a usable first draft: label candidate keywords clearly, leave search volume/difficulty/traffic empty or "to be checked," and do not fabricate values.

Only collect sufficient data to support the current decision; do not force the client to purchase tools, export ten-thousand-keyword lists, or hit a fixed number of competitors. If the client already has a detailed keyword list and ranking URLs and wants deeper page architecture work, you may reference the installed $b2b-seo-site-architecture skill. This skill must be able to independently deliver the technology selection and initial SEO plan.

6. Deliver Discussable, Actionable Results

First, show the conclusions in the chat. Then deliver the following based on project scope—do not pad empty sections for the sake of a template:

1. Client Summary & Mode: Goals, constraints, known/assumed/missing items; clearly state whether it's an existing site audit, new site plan, or teaching example.
2. Current State & Competitor Gaps (Path A only): Actual visit scope, eight-layer technology snapshot, evidence table of features and plugins/themes; distinguish between confirmed observations, inferences, not found, and inconclusive; list worthwhile features and their priority.
3. Recommendation & Alternative: Eight-layer selection table with trade-offs explained; for Path A, compare keep/partial refactor/migration while protecting old URLs and active inquiries. Only include cost estimates if supported by budget data, and separate one-time from ongoing costs.
4. Plugin & Service Configuration List: Executable choices and configurations per the services specification. Do not write "planned" as "installed/verified"; include license/service costs and maintenance responsibilities.
5. CDN Selection & Rule Table: Per the CDN specification, provide specific setup, cache/bypass conditions, TTLs, cache keys and priority, update/fallback, verification results or acceptance steps. For unknown values, state the assumption clearly and give an executable placeholder with rationale.
6. SEO Page Blueprint: Core site structure tree and page mapping table, including target buyer, need/candidate keywords, URL, page type, content evidence, CTA, priority, and research status. Use plain Chinese for explanations; for English-language site page names/URL examples, use English. Article plan listed separately.
7. Operation Flow: Content editing → page update; visitor access → CDN/origin delivery; inquiry submission → storage → email sending → business inbox → reply/follow-up; chat branch describing online vs. offline handling.
8. Execution Order & Acceptance: Arrange by dependencies, using 30/60/90-day work plans if helpful; do not present dates as ranking or inquiry promises. Cover search visibility, core templates, language, performance, and the real inquiry chain.
9. Validation Boundaries & Next Steps: List the few gaps most likely to change the decision, how to fill them, sources, and check dates. For Path A, note that web-only observation may differ from actual back-end conditions; specify what requires back-end or stakeholder confirmation.

If the user does not request files, prioritize direct delivery in chat. Do not automatically create websites, purchase services, modify DNS, send messages, submit forms, publish pages, or alter existing sites. Build, SEO execution, or publishing are to be performed only under the user's subsequent actual authorization; research is not a go-live approval.

Examples & Acceptance

For users wanting to see examples or understand the output shape, read the Furniture Factory Full Example. The client, budget, fields, and keywords in the example are purely for demonstration and must not be treated as real client data or verified research.

Pre-delivery checklist:

• Path A: Was the site actually visited with page evidence? Are plugin inferences honest?
• Path B: Are conclusions derived from client answers?
• Are the client's platform preferences and existing site accounted for?
• Does the CDN plan include setup and rule tables, not just a brand name?
• Are page update and inquiry flows clear?
• Is the distinction between template/page count made?
• Are unknown data and uncertified examples kept as unknown?
• Is it clear what new conditions would require re-evaluating the primary solution?