The WordPress maintenance space has several decade-old incumbents — ManageWP, MainWP, WP Umbrella, InfiniteWP. Building a new entrant means inevitably fielding queries like "ManageWP alternative" and "WordPress maintenance tools comparison" — search intent that names a competitor or the category itself.
To handle that intent carefully, the LP runs a hub-and-spoke comparison structure. Here's how it's built and why.
What hub-and-spoke means
A hub-and-spoke pattern places one central page (the hub) and multiple related sub-pages (spokes) in a radial arrangement. The naming follows airline hub airports: the hub is the overview, the spokes are the per-item deep dives.
In an SEO context, that maps neatly onto search intent: broad overview queries go through the hub, narrow specific queries land on the spokes.
The implementation
[ /compare.php ] ← hub (overview table + decision guide for 5 tools)
│
├── /vs-managewp.php ← spoke 1
├── /vs-mainwp.php ← spoke 2
├── /vs-wp-umbrella.php ← spoke 3
└── /vs-infinitewp.php ← spoke 4
The hub (compare.php) centers on an at-a-glance table covering five tools (ours + four competitors) and a decision guide ("which team profile fits which option"). It catches early-stage comparison-shopping intent.
The spokes (vs-managewp.php etc.) are one deep-dive page per competitor, landing directly on competitor-name queries like "ManageWP vs".
What goes inside a spoke
Each vs page follows the same structure:
- 12-row spec table (pricing / connection model / supported scale / etc., side by side)
- Top 4 differences (the axes that matter most)
- Six in-depth sections
- "When [competitor] is a better fit"
- Parallel-trial procedure
- 5–6 FAQ items
Section 4 — "When [competitor] is a better fit" — is the structural lever. Vs-pages that read as one-sided promotion get flagged by both Google and readers, so explicitly conceding the competitor's genuine strengths in a structured section builds credibility for the page as a fair comparison.
There's a matching honest-review article on the blog for each competitor — for example, ManageWP's Strengths and Who It Fits. The split is intentional: LP pages cover the "us vs them" angle, blog articles cover the "competitor on its own merits" angle, so two different reader intents are each absorbed by the right format.
Cross-link mesh and sitemap priority
Each vs page links outward in four directions:
- vs → compare (back to the hub)
- vs → other vs pages ("See also")
- vs → the competitor's blog review
- compare → every vs page
No matter where Google's crawler enters from, the whole comparison set is reachable.
sitemap.xml priorities follow hub 0.9 / spokes 0.8:
<url>
<loc>https://wpmm.jp/compare.php</loc>
<priority>0.9</priority>
</url>
<url>
<loc>https://wpmm.jp/vs-managewp.php</loc>
<priority>0.8</priority>
</url>
The hub gets the higher weight because it's the natural entry point for the broader query space. JP and EN sitemaps use the same priority structure.
Tracking whether it's working
To verify the design is doing its job, we run daily search-rank tracking — 12 keywords total (7 JP + 5 EN), including "ManageWP alternative" and "wordpress maintenance" — recording the wpmm.jp rank in Google's results into a CSV each day.
Rank movement after the hub-and-spoke deployment becomes quantitatively visible, so structural changes' SEO impact can actually be followed rather than guessed at.
Takeaway — let two intents land on two surfaces
"ManageWP alternative" mixes two distinct search intents in one query — visitors looking for one specific competitor's replacement, and visitors trying to survey the entire category. Trying to serve both with a single page tends to produce a result that's neither deep nor broad.
Splitting into hub and spokes lets broad surveying happen on the hub and specific deep dives happen on the spokes — search-intent width matched to page structure. The implementation cost is "one vs page + one blog review per competitor," which a single person can handle when the field has only four or five major players.