Roadmap · Last updated: 2026-04-22

What we're building. And why.

This page serves two audiences at once. For customers and evaluators, it's a commitment signal: the product is being built with intent, and the team is transparent about what's in-flight vs. speculative. For the dev team, it's a scoping compass: every item is tagged with the existing primitive it builds on, so nothing here asks for greenfield engineering when an adjacent service already exists.

The framing (tool + playbook + consulting) is shaped by the copy plan dated 2026-04-22. The plugin automates the repeatable work; the playbook tells clients when a human should step in; our consulting is one of the handoff destinations. Roadmap items are evaluated against that shape: does this strengthen one of the three lanes, or blur them?

Principles that govern what gets on this list

  • Ship what Search Console actually supports. If a metric isn't available via the GSC Search Analytics API, we don't promise a product feature around it. “Impressions on AI Overviews” is a current research bet because Google surfaces it; “rank #1 on ChatGPT” is not on this roadmap because no primary-source data backs it.
  • No feature we can't evidence. Every item names the primitive in Plugnrank-app it extends, or it's flagged as research. We would rather cut an item than add a checkbox that misrepresents scope.
  • Consulting is a first-class lane, not a fallback. Items that only make sense with a human operator (auditing brand voice, interpreting ambiguous signals, rewriting YMYL-sensitive copy) stay in the Consulting lane and don't get re-scoped as plugin features just because it's easier to sell self-serve.
  • Transparency over polish. Rejected and deferred items stay visible at the bottom of this page. Users deserve to see what we considered and didn't pursue, along with why.
Now

In active development: next ~30 days

Items here have a branch, a ticket, or a working prototype. They are not promises of a shipping date, but of an allocation.

Non-branded traffic filter across plugin + dashboard

Plugin feature
Why now
Google's 2026-03 search rollout made branded-vs-non-branded separation a first-class GSC filter. Clients already ask us to ignore branded queries when prioritizing work.
What it looks like
A brand-term list per site; every GSC-derived report (Priorização, Sniper suggestions, monthly summary) can be toggled to non-branded only.
Builds on
Site + SiteSettings models; GSC ingestion path in the Search Analytics import.

Internal linking: opportunity report

Plugin feature
Why now
InternalLinkingService already injects links at publish-time; clients ask for a retrospective view of which existing posts are under-linked.
What it looks like
A per-site table ranking posts by “orphan score” (few inbound internal links relative to topical relevance).
Builds on
InternalLinkingService + Topic/Post graph.

Sniper-entry scoring tied to GSC deltas

Plugin feature
Why now
The Sniper (Step 4 in the playbook) needs a concrete surfacing rule. Currently the prioritization logic is applied at generation time. We want a weekly trigger that flags pages where the 28-day impressions-up/clicks-flat signature appears.
What it looks like
A scheduled job that runs post-GSC-import and writes a sniper_opportunity record against posts that match the pattern.
Builds on
SiteTopicScheduler cadence model; GSC import. Consulting lane consumes the output.
Next

This quarter

Items here have design intent and a rough scope but aren't in-flight yet. Sequencing may shift based on Now-lane completion and customer signal.

Additional LLM providers (Anthropic, Google)

Plugin feature
Why
GenerationProviders/ only contains OpenAiTopicGenerationProvider today. Redundancy protects against single-vendor outages and lets us match model capability to content type (long-form vs. short utility pages).
Constraint
Every provider must produce output compatible with the same TopicPromptBuilder contract; no per-provider drift in tone or structure.
Builds on
TopicGenerationManager + provider interface in Services/Posts/GenerationProviders/.

Brand-voice profile per site

Plugin feature
Why
Consulting clients consistently ask for tone-locked generation. Today the prompt is built per-topic; there's no persisted voice artifact.
What it looks like
A SiteVoiceProfile attached to Site with tone descriptors, banned phrases, reference passages; TopicPromptBuilder consumes it.
Builds on
Site, SiteSettings, TopicPromptBuilder. Consulting seeds the profile in the onboarding engagement.

Multilingual publishing flow

Plugin feature
Why
DefaultLanguage enum already exists; the generation path and publisher still assume a single-language site. We have demand from pt-br/en bilingual clients.
What it looks like
Per-topic locale selection, parallel publish attempts per locale, hreflang wiring on the WordPress side.
Builds on
DefaultLanguage, SiteTopic, WordPressCmsPublisher.

Agency console: cross-site view

Plugin feature
Why
Site + SiteInvitation already model multi-site. Agency clients need a single pane to see pipeline health across all their managed sites without switching tenants.
What it looks like
A scoped view that aggregates generation queue, publish-attempt failures, and sniper opportunities across all sites the user has access to.
Builds on
SiteInvitation, scoped queries on SiteTopic / SiteCmsPublishAttempt.
Later

Beyond this quarter: directional

These are active bets but don't yet have commitment-level detail. Exact scope depends on research outcomes and what Now/Next teaches us.

Additional CMS publishers (Ghost, Webflow)

Plugin feature
Why
CmsProvider enum + CmsPublisherRegistry are already designed for multiple publishers; WordPressCmsPublisher is the only implementation today. A second publisher proves the abstraction and opens a new ICP.
Constraint
Each new publisher must map to the same PublishResult contract and be testable without a live CMS.
Builds on
CmsPublisherRegistry, CmsPublisher contract, PublishResult.

AI-search visibility monitoring (research)

Research
Why
Customers keep asking “will this rank on ChatGPT?”. We won't promise ranking, but we can report on the visibility signals that do exist: impressions on AI-enhanced SERP features via GSC, mentions of the client domain in Perplexity's citation graph (when exposed), etc.
Current status
Research. We need to confirm which signals are reliably available before scoping a product feature.
Constraint
No copy or UI may imply we can guarantee placement or ranking in any LLM-surfaced context. FTC enforcement posture (Air AI, Workado) rules out promissory language regardless of novelty.

Earned-citations monitoring

Plugin feature
Why
DiffbotCitationService already runs at generation time. A retrospective monitor (“who cited our posts after they shipped”) turns the same data source into a retention argument.
Builds on
DiffbotCitationService + external link graph.

Editorial calendar with human review checkpoints

Plugin feature
Why
SiteTopicScheduler already runs the cadence. The missing layer is a calendar UI that supports human approval gates for YMYL topics (health, finance, legal).
Constraint
The gate must default to off for existing sites. Turning on review for a site in production should never silently pause publishing without explicit action.
Builds on
SiteTopicScheduler, SiteTopicStatus. Consulting advises on which topics deserve a gate.

Out of scope (deliberate non-goals)

These are not on the roadmap, and this section exists so the decision is visible instead of silently dropped.

  • “Rank guarantee” features of any form. No feature will promise a specific ranking, position, or visibility outcome. The legal and epistemic cost outweighs any conversion lift.
  • Backlink exchange / PBN-adjacent tooling. Would clash with client sites' E-E-A-T exposure and Google's link-spam policy.
  • One-click Google-Ads / paid-media orchestration. PlugnRank is organic-growth infrastructure. Paid-media tooling is a different product that different people operate; we would rather integrate with an existing ads platform than rebuild it.
  • Self-serve “generate 1000 posts and auto-publish” mode. Would contradict the plugin's daily-limit posture (1/5/15 per plan) and the whole “automation inside guardrails” positioning.

How this roadmap is maintained

  • Reviewed monthly by the product lead. The “Last updated” field above is the authoritative freshness signal.
  • Items move Later → Next → Now based on two checks: (1) is there a named owner, and (2) is the primitive it builds on still stable? If a primitive is being rewritten, dependent roadmap items pause until the rewrite lands.
  • Completed items graduate to the product changelog (not listed here; the roadmap is forward-looking by definition).
  • Rejected items migrate to “Out of scope” above with a one-line reason.

Ready to start?

Start with the Start plan ($10/mo) or book a 30-minute diagnosis to check whether the method fits your case.