Group SEO is a different problem, not a bigger one.
A single-rooftop dealer competes with the market. A twelve-rooftop group competes with the market and with itself, and the second fight is the one nobody is measuring.
One platform codebase serving many stores produces near-identical model pages, service pages, and location pages at every rooftop. That is not a defect; it is what makes the platform economical. But it means a group frequently has five or six URLs targeting the same query, none of which accumulates enough authority to win it, while a single-store competitor with one good page takes the position.
Then acquisitions add legacy domains, redirected sites nobody audited, and a few hundred blog posts written by three different vendors across eight years. The group's biggest SEO competitor is usually the group.
Most vendors treat a group as N single-store engagements running in parallel, which is how the cross-rooftop problem stays invisible: every individual store report looks fine, and the aggregate underperforms.
The allocation that avoids it is specific: local, service, and specialty inventory content stays per rooftop, while model, research, and warranty content consolidates at group level. Getting that split wrong is what produces eight stores holding one store's worth of visibility. The per-rooftop local layer → · How the keyword categories divide →
- Duplicate model pages
- The same trim page at every rooftop, competing on the same query in overlapping DMAs.
- Location page overlap
- Two stores 14 miles apart both targeting the same city term.
- Acquisition debt
- Legacy domains, half-finished redirects, orphaned content from prior vendors.
- Inconsistent entity data
- Twelve rooftops described twelve different ways across listings, which is fatal to AI citation.
The cannibalization map.
This is the first thing built on a group engagement, before any content gets written, because writing new pages into an un-mapped group domain usually makes the problem worse.
Every URL on the group's domains, inventoried against every query with clicks or impressions in Google Search Console, with overlap scored and consolidation candidates flagged. Not a sample. Not the top 100 pages. Everything.
From there the work splits three ways:
- Consolidation. Merge or redirect the overlapping pages so one canonical answer compounds authority instead of five half-versions splitting it. This frequently produces the largest single movement in a group engagement, and it involves deleting pages, which most vendors are reluctant to recommend because it looks like less work.
- Differentiation. Where two rooftops genuinely need to rank in overlapping geography, the pages get deliberately separated by intent and market rather than left to compete by accident.
- Inventory-aware content. New pages mapped to what buyers actually research, scoped against what the group actually sells, with each new page earning a query the group does not already win, or not getting built.
The map is yours to keep. If the engagement ends, it leaves with you, and it stays useful because it documents the shape of the domain rather than a moment in time.
Publishing content into a group domain with unresolved cannibalization is like adding runners to a relay where everyone is running in a different direction.
The content actions in month one usually include deletions. That is not a smaller deliverable, it is the one with the highest expected value, and it is why the monthly allocation is described as "content actions" rather than "blog posts."
Priced per rooftop, discounted by group size.
A group does not pay the posted rate multiplied by store count. The discount is banded by rooftop count and applies to every store in the group, not only the ones past the threshold: 10% off at 2–3 rooftops, 20% at 4–7, 28% at 8–14, and 32% at 15 or more. The audit, the schema baseline, the entity work, and the reporting infrastructure get built once and then serve every rooftop, which is what pays for the curve.
Onboarding is a flat one-time fee charged once per group, never once per store. Compete is $1,615 per rooftop and Command is $2,425, each with its own onboarding figure.
There is no rooftop cap and no enterprise tier that exists mainly to trigger a call. A fifteen-store group is priced the same way a three-store group is, just further down the curve. Every rate is in the table, so the total is something you can work out before you talk to anyone.
| Rooftops | Off | Core | Compete | Command |
|---|---|---|---|---|
| 1 | — | $1,165 | $1,615 | $2,425 |
| 2–3 | 10% | $1,048 | $1,454 | $2,182 |
| 4–7 | 20% | $932 | $1,292 | $1,940 |
| 8–14 | 28% | $839 | $1,163 | $1,746 |
| 15+ | 32% | $792 | $1,098 | $1,649 |
The band applies to every rooftop in the group, not only the stores past the threshold. Onboarding is charged once per group at the tier's flat rate.
Two layers, because two audiences need different things.
Per store
- Search Console movement for that rooftop's own query set, not a group average that hides a struggling store.
- Content actions taken at that store this cycle, with the URLs.
- AI citation status in that store's actual market, including which local competitors are getting named instead.
- Technical execution log: what changed, on which URLs, why. Written to be handed to a platform vendor without translation.
Group level
- Portfolio roll-up so leadership can read one document instead of twelve.
- Internal competition view: where rooftops are still fighting each other rather than the market. This is the number that does not exist in per-store reporting.
- Allocation rationale: which stores received the month's content actions and why, since the allocation is decided by data rather than split evenly.
- Quarterly business review against the plan, with what changed and what it moved.
Cadence is monthly at Core and biweekly at Compete and Command, matched to how the underlying signals actually move rather than to the invoice cycle. Full deliverables breakdown →
Built to be held to a deliverable.
Groups with an internal digital operations lead are the easiest engagements to run well, because there is someone who understands the platform constraints and can get changes deployed without a three-week ticket queue.
For that person, the things that matter are documentation and accountability, so both are structural rather than on request:
- Stated monthly volume. 6 content actions at Core, 12 at Compete, 18+ at Command. A number you can check.
- Stated cadence. Reporting and strategy sessions on a fixed schedule, defined per tier.
- Execution log every month. What changed, which URLs, why. Enough for an internal team or a platform vendor to act on directly.
- Documented platform ceilings. Anything your platform will not permit gets written up in a form you can forward to your vendor as a support request.
- Direct access to the operator. No coordinator relaying a technical question to someone technical and returning with an approximation of the answer.
Mixed-platform groups after an acquisition are common and workable. What is possible at one rooftop may not be possible at another, so the plan gets scoped per platform even though strategy is set at group level. Platform-by-platform detail →
VulcanAX takes a maximum of five dealer groups at a time, with no rooftop limit inside a group.
That cap is what makes it possible for the person who scopes the work to also execute it. It also means availability is genuinely finite, and the honest answer to a new inquiry is sometimes that there is no room this quarter.
One client per market is absolute. Two competing rooftops never get optimized against each other, which is a thing larger shops do routinely and rarely disclose.
What group principals and ops managers ask.
What is keyword cannibalization in a multi-rooftop dealer group?
It is when several pages across the group compete for the same query, so no single page accumulates enough authority to win it. In a group it is structural rather than accidental: one platform codebase serving many stores produces near-identical model, service, and location pages at every rooftop. Add legacy blog content nobody owns and a group can have five URLs competing for one buyer. Consolidating them so a single canonical answer compounds is usually the highest-value action available on a group domain.
How is SEO priced for a multi-rooftop dealer group?
Per rooftop per month, with a banded volume discount applied to every store in the group: 10% off at 2–3 rooftops, 20% at 4–7, 28% at 8–14, and 32% at 15 or more. At Core that is $1,048, $932, $839, and $792 per rooftop; at Compete $1,454, $1,292, $1,163, and $1,098; at Command $2,182, $1,940, $1,746, and $1,649. A six-rooftop group on Compete pays $1,292 per rooftop, or $7,752 per month, plus $1,500 onboarding once. Onboarding is charged per group rather than per store. Full pricing here.
Is there a limit on how many rooftops you can handle?
No. There is no rooftop limit inside a group. The cap is on groups rather than stores: VulcanAX takes a maximum of five dealer groups at a time. A fifteen-rooftop group is priced and run the same way a three-rooftop group is, just further down the volume curve.
How does reporting work across multiple rooftops?
Two layers. Per-store reporting shows what happened at each rooftop: its own Search Console movement, its own content actions, its own AI citation status in its own market. Group-level reporting rolls that up so leadership reads one document instead of twelve, and includes the internal-competition view showing where rooftops are still fighting each other rather than the market. Cadence is monthly at Core, biweekly at Compete and Command.
Can you work with a group whose rooftops are on different platforms?
Yes, and it is common after acquisitions. Mixed-platform groups are harder in one specific way: what is possible at one rooftop may not be possible at another, so the plan is scoped per platform even though strategy is set at group level. That difference gets documented rather than averaged away into a plan that only works on half the stores. Platform detail here.
Will you work with our competitor in the same market?
No. VulcanAX holds one client per market and does not optimize competing rooftops against each other. Iowa is closed statewide, and one additional market is closed. Every other US market is open, though a market closes the moment a group inside it signs.
How does this work alongside our internal marketing team?
Directly, and usually well. A group with an internal digital operations lead is the easiest kind of engagement to run, because there is someone who understands the platform constraints and can get changes deployed. Deliverables are written to be handed to an internal team or a platform vendor without translation, including a monthly execution log of what changed on which URLs and why.
Can you support SLA-based vendor management?
Yes. Every tier carries a stated monthly content-action count (6 at Core, 12 at Compete, 18+ at Command), a stated reporting cadence, and a stated strategy-session cadence. Each month produces a technical execution log recording what changed, on which URLs, and why. That is the documentation an operations manager needs to hold a vendor to defined deliverables, and it exists by default rather than on request.
Send a rooftop count and a platform.
That is enough to come back with a group rate and a read on where the rooftops are competing with each other, before any call happens. Five groups maximum, one per market. Iowa is closed statewide; one additional market is closed.