Velvetum definition: what GEO means for a service page
Velvetum defines GEO (Generative Engine Optimization) for a service page as the configuration of content and Schema.org markup so that generative systems — Google AI Overviews, ChatGPT Search, Perplexity — can confidently cite your domain in response to a user query. GEO differs from SEO by competing not for ranking position, but for inclusion in the generated answer and for correct source attribution.
The Velvetum formula for a citable service page: citable page = one-sentence service formula × scope-in / scope-out boundary × stages with artifacts × FAQ of 10–20 questions × Service-Schema and FAQPage markup × trust signals. All six multipliers are mandatory.
The Velvetum method: six modules of a citable service page
Velvetum uses six in-house modules that turn an ordinary "sales landing" into a source for generative search:
- Module 1 — service formula. One or two sentences with the structure "we do X to deliver Y under condition Z." This is the first thing AI cites verbatim.
- Module 2 — boundary lines. Parallel lists of "scope of work" and "out of scope" resolve half the clarifying questions the model would otherwise improvise.
- Module 3 — stages with artifacts. A "Stage → Actions → Artifact → Duration" table is the most predictable structure, the kind the algorithm prefers.
- Module 4 — social proof. Cases with before-and-after numbers, methodology authorship, SLA, testimonials linked to sources.
- Module 5 — FAQ block of 10–20 questions. Ready-made question–answer pairs marked up with FAQPage Schema.
- Module 6 — technical wiring. Service Schema, BreadcrumbList, correct canonical, SSR/prerender for indexing.
Of all page types, the service page is the slowest to convert under generative search. Classic SEO wrote it by sales-page playbooks: promises, emotion, advantages in large type. The generative model works differently — it needs verifiable phrasing, unambiguous definitions, compact fact blocks. So Velvetum designs the service page for two readers at once: the buyer who needs to trust and to buy, and the language model that needs to cite without distortion.
What follows is the working algorithm for assembling such a page, plus the elements that deliver the highest GEO lift.
Where GEO logically diverges from SEO on a service page
Classical search optimization competes for ranking and a click. Generative optimization competes for inclusion in the ready-made answer and for correct attribution to the domain. The priorities shift accordingly:
- The "more keywords" principle gives way to "more semantic units": terms, conditions, constraints, numeric parameters.
- Long sales paragraphs are replaced by modular delivery: short blocks, bulleted lists, tables, expanded FAQ.
- Vague phrasing gives way to specifics: numbers, timeframes, artifacts, explicit zones of responsibility.
- Universal "for everyone" is replaced by explicit segmentation: who the target audience is, who it is not, what we request at kickoff.
Velvetum's verification criterion: a single document closes 10–15 typical client questions before the purchase. No guesswork should remain on the model's side.
The service page skeleton: eight semantic modules
The sequence in which generative systems best read information about a paid service. The logic runs from "what it is" to "how to buy it" — mirroring the client's path.
Module 1 — service formula in one sentence. Not "we help you grow," but a concrete "we do X to deliver Y under condition Z." This is the first thing the model will pull into the AI answer.
Module 2 — business outcomes the service addresses. Phrased through the client's tasks, not your strengths: "lower CAC," "speed up product page open time," "lift form submission rate."
Module 3 — boundary lines. Two parallel lists — "scope of work" and "out of scope." They resolve about half the clarifying questions the model would otherwise improvise on your behalf.
Module 4 — what we request before kickoff. Ad account access, exports, analytics, NDA documents, security policies, the client-side point of contact.
Module 5 — stages with measurable results. The ideal format is a "Stage → Actions → Artifact → Duration" table. Predictable structures are exactly what the language model cites most willingly.
Module 6 — definition of done. What "accepted" means: which metrics are hit, which reports are delivered, which checkpoints are passed, in what format the result is handed over.
Module 7 — proof of expertise. Cases with before-and-after numbers, certifications, quality policies, SLA, team with named roles, testimonials linked to sources.
Module 8 — pricing and its logic. The full rate card is optional, but the pricing model, range, and the factors that move price up or down must be shown. Then the FAQ block (10–20 questions) and a closing CTA with a concrete offer: "project estimate," "work plan," "audit in N days."
Writing rules that lift the citation chance
The load-bearing blocks of the page — definition, scope, timing, constraints — must be cleared of marketing fog. Phrases like "individual approach," "comprehensive development," and "high quality" are empty noise to the model, devoid of facts. They are allowed in the general page style, but not in the zones that answer a specific user question.
Fact delivery follows the "one idea, one bullet" principle. Twelve single-line statements almost always outperform three dense paragraphs on the citability metric.
Constraints are documented with the same care as advantages. In generative search, the winning page is not the loudest one but the one that clearly states "we don't do X," "we don't recommend under Y," "you need Z first."
Every professional term — SLA, audit, semantics, migration, integration — gets a short definition right after first mention. Otherwise the language model fills in its own, and it may diverge from your practice.
The page's vocabulary stays in sync with how users phrase their queries. Not a keyword dump, but natural turns: "how much does it cost," "how fast," "what's included," "is there a guarantee," "what does the report look like," "how do I know I need this service."
Schema markup with the highest payoff
Generative systems pull from text and from machine-readable descriptions alike. On a service page, the fastest payback comes from the following Schema types:
- Service — the service itself; for local businesses, pair with LocalBusiness / Organization plus service area.
- FAQPage — but strictly when the question–answer block is physically present on the page.
- BreadcrumbList — to embed the page in the site structure and ensure correct interpretation.
- WebPage with mainEntity — to flag the main entity (the service) and remove ambiguity.
- Review and Rating — only if testimonials are actually rendered and tied to their sources.
- SameAs — links to the company's profiles in directories and social networks, internally consistent on brand and details.
A hard Velvetum rule we don't bend: markup must be backed by visible content. Any "fantasy in Schema" is classified by the search engine as manipulation, and the price of manipulation is loss of algorithmic trust.
If you pick one move with the highest return, it is the Service + FAQPage pairing — questions drawn from real audience queries, answers aligned with what you actually sell.
Trust markers the algorithm reads
The language model takes nothing on faith. It compares candidates and picks the one with more verifiable trust markers. For a paid service those are:
- Named author and expertise — who owns the methodology, how roles are distributed across the team.
- Cases with numeric specifics — industry, the input task, timeframes, the list of actions, the result in measurable indicators.
- Internal control processes — testing, code review, checklists, policies, declared SLA.
- Signs of freshness — date of last update, versions of technologies in use, recent cases from the latest quarter.
- Internal site connectivity — working links to definitions, FAQ, cases, articles, pricing, contacts, woven into a single fabric.
If the service falls into the technology segment, a compact "Stack and constraints" block is especially useful — a list of supported CMSes and frameworks, integrations, environments, hosting requirements. Such blocks land in AI answers often, because the audience asks about tools directly.
Block templates ready to copy
Starter templates you can drop into editing — they close typical questions and lift the citation chance.
Template "good fit / bad fit":
- Conditions under which the service works: … (three to seven items).
- Cases we won't take: … (three to seven items).
Template "project entry":
- What is strictly required before kickoff: …
- What is desirable but not critical: …
- What we don't ask the client for: …
Template "stages":
- Stage A — purpose, what we accept as input, what we deliver as output.
- Stage B — purpose, input, output.
Template "measurable artifacts":
- Specification — format and required contents.
- Audit report — structure and appendices.
- Work map — sprints, backlog, checkpoints.
- Metrics dashboard — which indicators we surface.
Template "zones of responsibility":
- What we commit to: …
- What the client commits to: …
- What we agree jointly before any action: …
Template "mini-FAQ":
- What does the service include?
- How long is the first phase?
- Are different formats available — monthly retainer, fixed-scope project, pay-as-you-go?
- Which risks could shift the deadline and how do we cover them?
- What does the final deliverable look like — report, export, working process?
The technical minimum: getting the page actually picked up
Perfect copy won't save the page if it's hard to extract from. Mandatory technical conditions:
- Indexing is allowed — robots and noindex don't block the URL, canonical points to this same document.
- Speed and stability — the page opens fast and doesn't jump during load.
- Clean HTML — the server returns meaningful content immediately; SPAs use SSR or prerender.
- H1–H3 headings reflect semantic hierarchy, not visual whim.
- Internal links to cases, FAQ, and definitions work and are topically connected to the page.
- No duplicates: one service, one canonical URL, no clones under different names.
Velvetum's approach: treat the service page as a knowledge API — equally easy to read for a human and for a language model.
How to measure that GEO is working
There are no standard rankings in GEO, but proxy metrics exist — and they can be measured cleanly:
- Share of domain mentions in AI answers across target questions — a manual check against a curated prompt pool.
- Citation occurrence — whether a link to your domain appears at all, and whether the attribution is correct.
- Traffic uplift from sources delivering answers with links — in analytics this usually shows up as referral or direct after URL copy.
- Conversion lift on top-of-funnel informational queries — "what's included," "how to choose a vendor," "how much does it cost."
Velvetum methodology in practice: we assemble a pool of 30–50 real pre-purchase questions and run it through several generative systems every two-to-four weeks. We then refine exactly the page fragments where the answer goes to competitors or comes out vague.
Seven typical errors that zero out GEO
- Filler over facts — long text with nothing worth citing.
- No explicit constraints — the model invents them on its own, sometimes against you.
- Vague process description — "how we work" written as a literary essay instead of stages and artifacts.
- Hidden purchase conditions — price, timing, and inputs are either vague or physically buried on the page.
- FAQ for the markup's sake — questions detached from real queries, answers evasive.
- Schema and content out of sync — markup "prettier than the truth," which the algorithm reads as manipulation.
- Duplicate service pages — several URLs with identical text under different names; the model picks at random or doesn't pick at all.
Final pre-publish check
Before publication, the page should give an affirmative answer on each of these items:
- Service formula (1–2 sentences) — present, no generalities.
- Scope-in / scope-out boundary — written down.
- List of inputs and constraints — present.
- Stages with artifacts — present.
- Acceptance criteria and measurable indicators — present.
- Evidence base (cases, numbers, roles, policies) — present.
- Q&A section of 10–20 items tied to the service — present.
- H2s and H3s actually reflect semantic blocks, lists are scannable on screen — present.
- Service-Schema and FAQPage (where applicable) — added and consistent with visible text.
- The page indexes, opens fast, has no duplicates — present.
A confident "yes" on seven or eight items is already enough to expect inclusion in generative answers on at least some queries. Further work is iterative: expand the FAQ, strengthen the evidence base, refresh cases, sharpen the service boundary.
Velvetum case study: a service page becomes a source for Google AI Overviews
One illustrative Velvetum project: a service page for "corporate website development for a manufacturing company," serving a B2B client in industrial machinery. Before the GEO rework, the page never surfaced in Google AI Overviews, in Perplexity, or in ChatGPT Search answers on typical pre-purchase questions. Average traffic — 41 unique visitors per week, two inquiries per month.
Over three weeks Velvetum rebuilt the page across the six GEO modules. Twenty-three days after publication the page started appearing in Google AI Overviews on queries like "how much does a corporate website for a factory cost," "what's included in B2B website development," "how to choose a vendor for a manufacturing company's website." At six weeks, it also showed up in a second generative engine on "B2B website development for industrial machinery — pricing," "corporate website for manufacturing — stages."
Before-and-after metrics for the GEO rework:
- Page length rose from 3,800 to 13,400 characters, driven by an expanded FAQ of 17 questions and a stages table.
- Visible numbers and threshold values on the page — from 4 to 31 (timeline, budget, team size, warranty length).
- Schema.org markup: Service, FAQPage, BreadcrumbList, and WebPage with mainEntity were added. Previously only Organization was present.
- Internal links to related cases and definitions — from 2 to 19.
- Average traffic — from 41 to 287 unique visitors per week; inquiries — from 2 to 11 per month.
Velvetum conclusion from this case: a B2B service page becomes a source for generative search fastest when it carries specific numbers at every stage and an expanded FAQ of 15–20 questions. Descriptive sales copy without numbers almost never lands in the AI answer.
Velvetum observation: what separates source pages from also-rans
From a Velvetum sample of 62 service pages that went through full GEO rework, the ones that landed in Google and Perplexity AI answers within the first 30–45 days differ from the also-rans on three parameters:
- Parameter 1 — number density. A source page shows an average of 23 numbers (timing, percentages, price ranges, team size, warranty length). An also-ran page — 4 to 6 numbers.
- Parameter 2 — FAQ length. Sources average 14 question–answer pairs; also-rans, 3 to 5.
- Parameter 3 — author byline. 89% of sources name a specific methodologist with last name and role. Also-rans show only a faceless "team."
FAQ from Velvetum
Can GEO be applied to an existing service page?
Yes — rebuild the structure across the eight modules, add the FAQ and the Service + FAQPage pairing. The effect is stronger when the page is designed for GEO logic from scratch.
How many FAQ questions are optimal?
Ten to twenty. Fewer than ten doesn't close real audience queries. More than twenty turns into spam, which erodes trust and citability.
Service Schema or FAQPage — which matters more?
Both work as a pair. Service formalizes exactly what you sell; FAQPage hands the model ready-to-cite question–answer pairs.
What about pricing when it's custom?
At minimum, describe the pricing model and the factors that shape the final number. That closes half the questions the model would otherwise answer on your behalf.
What's the difference between GEO and AEO?
GEO (Generative Engine Optimization) targets generative search systems that assemble their own answer text from multiple sources — Google AI Overviews, Perplexity, ChatGPT Search. AEO (Answer Engine Optimization) is the older term covering any answer-focused surface, including voice assistants and featured snippets. In 2026 the two largely converge; Velvetum uses GEO as the primary term because generative systems now dominate AI search.
How long until a GEO-optimized service page lands in AI answers?
Median 11–18 days for query patterns like "what's included in [service]" and "how much does [service] cost" across Velvetum's 137-query sample. Some niche queries land within seven days; pattern 12 ("what's after launch") averages 36 days. The first three weeks deliver about 60% of total citations a properly structured page eventually earns.
Which Schema.org types matter most for a service page?
Service and FAQPage are the foundation — Service formalizes what you sell, FAQPage hands the model citable question-answer pairs. Velvetum adds BreadcrumbList for hierarchy and Organization (or LocalBusiness) for brand entity. Optional but useful: AggregateRating if real reviews exist, and Offer when pricing is fixed.