It is a routed page generated from a data source that compares two historical or stylistic eras side by side. Unlike a blog post, you do not create it in the WordPress editor. You add a row to the data source, the plugin renders the page on demand.

Yes. SleekRank supports multiple page groups simultaneously. You can run /era/{slug}/, /yoy/{slug}/, and /decade/{slug}/ together. Each group has its own data source, its own base page, and its own field mappings, so they do not interfere.

Append the row to your data source, run a delete on the SleekRank items table to clear the cache, and flush rewrites once. The new routed URL is live as soon as a visitor or crawler hits it. No editor session, no publish click, no redeploy.

Yes. The shared FAQ component on the base page outputs FAQPage JSON-LD, and each routed page substitutes the per-row faqs field into that schema. So every era pair page can show up in Google rich results for its specific questions.

Each row defines its own column list and row values, so era pairs with different dimensions like ornamentation, voicing, or harmonic language can each use the columns that fit. The base page reads the column list from the row at render time.

The plugin uses the slug as a key into the resolved items cache. If you create a duplicate, the last row wins on resolution. Most teams add a CI check on the data source to flag duplicates before they ship, since the impact is silent otherwise.

Not when the per-row content carries enough unique value. The header, table, lead text, and FAQs change per pair, which is the substance Google evaluates. Shared scaffolding like a comparison header or a CTA is fine across the cluster.

Not directly. SleekRank renders dynamically through the WordPress page lifecycle. Most teams add a page cache layer on top, which gives static-like performance without removing the data-driven update flow that makes the archetype useful.