Skip to content

Refresh PerformWP site content around 1.6.0 positioning and conversion paths #187

Open
Open
Refresh PerformWP site content around 1.6.0 positioning and conversion paths#187
Labels
area: docsDocumentation URLs, help links, readme copy, changelog, or support guidance.area: frontendPublic-facing frontend output, assets, feeds, headers, or visitor behavior.enhancementFeature or improvement request that changes product behavior or user experience.priority: mediumUseful or user-impacting work that should be planned but is not blocking now.status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.
Milestone
Backlog

Description

@mehul0810
mehul0810
opened on Jul 7, 2026

Context

Authority & Growth audit on 2026-07-07 found that the live PerformWP site has a small content inventory and several high-value pages lag behind current product positioning.

Verified sources:

  • PerformWP MCP content inventory: 11 published pages, 3 published posts, 24 published docs.
  • Public sitemap review: homepage refreshed in 2026; posts and docs refreshed selectively in 2025.
  • Current product listing describes newer 1.6.0 capabilities such as redesigned Assets Manager, full-page cache controls, safer cache writes, scanner interface, validation, and current metadata.
  • Public site feature, audit, and docs pages still use older titles, metadata, repeated copy, or sparse content in several places.

Proposed scope

  1. Refresh /features/ to reflect current product capabilities.
  • Replace repeated placeholder descriptions across feature cards.
  • Add current feature clusters: Assets Manager scanner, page cache controls, response validation, stale regeneration and preload scheduling, observability stats, WooCommerce controls, CDN, preconnect, DNS prefetch, and Menu Cache.
  • Add contextual links into the most relevant docs.
  1. Refresh the introductory product post or replace it with a current evergreen overview.
  • Explain what Perform does now, who it is for, and where it fits in a WordPress performance workflow.
  • Include current release positioning without unsupported performance claims.
  • Link to docs, features, GitHub, the product listing, and the audit page.
  1. Rework /web-performance-audit/ as a stronger conversion page.
  • Add who should request an audit, what the report includes, expected inputs, deliverables, proof/trust signals, and the next step.
  • Fix stale internal links where found.
  1. Improve /docs/ as a documentation hub.
  • Replace generic archive metadata and thin archive copy.
  • Surface feature groups and high-intent docs.
  • Add links from feature pages into related docs.
  1. Prepare one new educational comparison or solution draft after the refreshes.
  • Suggested first draft: WordPress Asset Manager vs Cache Plugin: What Each One Optimizes.
  • Keep public copy competitor-neutral and avoid unsupported rankings or Core Web Vitals guarantees.

Acceptance criteria

  • Content changes are prepared as WordPress drafts/previews or repo/site PRs before publish.
  • No public content is published without owner approval.
  • No raw Custom HTML blocks are introduced.
  • Rank Math titles and descriptions are updated for affected pages.
  • Internal links are added between feature, docs, blog, product listing, GitHub, and audit conversion paths where relevant.
  • Screenshots are captured before and after any visible page design changes.
  • Performance claims are conservative and tied to supported product behavior.

Validation

  • Draft/previews open successfully.
  • Block validation passes with registered blocks.
  • Metadata is visible in Rank Math or equivalent SEO tooling.
  • Internal links resolve to live intended URLs.
  • Any design-visible change includes screenshot proof.

Activity

  1. mehul0810
    added this to the Backlog milestone on Jul 7, 2026
  2. mehul0810
    added
    enhancementFeature or improvement request that changes product behavior or user experience.
    area: docsDocumentation URLs, help links, readme copy, changelog, or support guidance.
    area: frontendPublic-facing frontend output, assets, feeds, headers, or visitor behavior.
    priority: mediumUseful or user-impacting work that should be planned but is not blocking now.
    status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.
    on Jul 7, 2026

  3. mehul0810 commented on Jul 12, 2026

    @mehul0810
    mehul0810
    on Jul 12, 2026
    CollaboratorAuthor

    Authority lane update, 2026-07-12:

    • Live-rechecked PerformWP Site MCP inventory: 11 published pages; 3 published posts plus drafts #772, #776, and #778; 24 published docs plus draft #773.
    • Duplicate screen: Refresh PerformWP site content around 1.6.0 positioning and conversion paths #187 remains the matching durable task for the content refresh; no separate issue was needed for the comparison draft.
    • Draft-only review of post #776 (WordPress Performance Optimization Checklist) found it still unpublished, categorized as WordPress Plugin, about 925 indexed words, with existing internal links into homepage, tips, features, audit page, and related docs.
    • Remaining owner-review items for #776: no featured image/tags, and publication needs owner approval for positioning around Core Web Vitals and Perform's role.
    • Prepared next educational draft, not published: post #778, WordPress Asset Manager vs Cache Plugin: What Each One Optimizes, edit URL: https://performwp.com/wp-admin/post.php?post=778&action=edit
    • Block validation passed for #778 using registered core heading/paragraph/list/list-item blocks. Rank Math title, description, and focus keywords were set.
    • Public publication still requires owner approval.

  4. mehul0810 commented on Jul 12, 2026

    @mehul0810
    mehul0810
    on Jul 12, 2026
    CollaboratorAuthor

    Brand-perspective page review, 2026-07-12:

    Reviewed current published pages through PerformWP Site MCP and live page metadata/copy. The homepage has moved toward clearer positioning ("Make WordPress Load Faster Without Breaking Your Site"), but the supporting pages still dilute the brand.

    Key brand gaps to include in the #187 refresh:

    • Brand system memory is incomplete: saved brand context has name, tagline, and logo only. Colors, tone, audience, image style, typography notes, and avoid-list are empty. This makes future content/page work rely on inference instead of a stable brand baseline.
    • Homepage has the strongest current positioning, but it needs clearer proof/trust support around "without breaking your site": reversible controls, conservative defaults, WordPress-native workflow, screenshots, and current WordPress.org metadata.
    • Features page is the biggest brand mismatch. It still uses repeated/placeholder descriptions across feature cards, with several features using unrelated copy. This makes Perform feel less mature than the current WordPress.org listing and screenshots.
    • Docs page reads like a generic archive ("Docs Archive - Perform") instead of a product documentation hub. It should reinforce Perform's categories: asset control, WordPress cleanup, CDN/resource hints, WooCommerce, cache/menu behavior, and safe rollout.
    • Web Performance Audit page is too thin to support the brand promise. It should explain who it is for, what the audit includes, what input is needed, what output the user gets, and why PerformWP is credible to advise on this.
    • Contact and Subscribe pages are generic utility pages. Contact should separate support, feature requests, and audit/commercial inquiries. Subscribe needs an actual value proposition or should be de-emphasized if not active.
    • Brand voice is inconsistent: homepage is sharper and current, older pages use generic or casual phrasing ("shoot us an email", "match made in heaven", repeated SEO claims). Recommended voice: practical, technical, conservative, WordPress-native, safe-change oriented.

    Suggested owner decision before page rewrites:

    Define the brand baseline as: "Perform helps WordPress site owners and builders make safer, reversible performance optimizations by controlling unnecessary assets, WordPress defaults, resource hints, and performance-related workflows without requiring custom snippets."

    Publication/change guardrails remain unchanged: prepare drafts/previews first; no public page changes without owner approval; capture screenshots for visible design changes.

  5. mehul0810 commented on Jul 12, 2026

    @mehul0810
    mehul0810
    on Jul 12, 2026
    CollaboratorAuthor

    Features page preview/spec for #187, 2026-07-12

    Scope: draft-only / dry-run-only replacement plan for https://performwp.com/features/

    No public content was changed. MCP dry runs validated the proposed page content and Rank Math SEO fields against existing page ID 40.

    Verified source signals

    • PerformWP Site MCP content index is current as of 2026-07-12 03:45:41, with no stale indexed rows.
    • Current published Features page: page ID 40, title "Features", slug "features", 266 indexed words, modified 2021-02-07.
    • Current page evidence: screenshot captured at output/playwright/performwp-features-current-2026-07-12.png.
    • Current visual issue from screenshot/source: generic theme title, no current product intro, feature names rendered as large stacked headings, and repeated or mismatched descriptions such as CDN/SSL copy appearing under unrelated features.
    • Current Rank Math/live metadata: title "Features - Perform"; meta description repeats the Assets Manager placeholder copy.
    • Current shipped product signal from WordPress.org plugin API: Perform 1.6.0, last updated 2026-05-26, active installs 200+, 5-star rating from 2 ratings, tested up to WordPress 7.0.1.
    • Current shipped feature set from WordPress.org/readme/changelog: redesigned Assets Manager with scanner workflow, full-page cache controls, safer cache writes, response validation, stale regeneration, preload scheduling, observability stats, cleanup controls, WooCommerce controls, CDN, DNS prefetch, preconnect, Menu Cache, hooks/filters, and clean uninstall behavior.
    • Saved brand context is still sparse: name, tagline, and logo exist; tone, audience, colors, image style, typography notes, and avoid-list are empty. Working brand baseline remains inferred from the site and Refresh PerformWP site content around 1.6.0 positioning and conversion paths #187: practical, technical, conservative, WordPress-native, safe-change oriented.

    Dry-run validation

    • MCP dry run: content_update_item, target page ID 40.
    • Proposed title: "WordPress Performance Features".
    • Proposed slug: features unchanged.
    • Proposed content: full replacement using only registered core blocks; no Custom HTML block.
    • Dry-run result: status preview, confirmation not required, warnings none.
    • Diff summary: replaces the current single legacy core/group wrapper containing UAGB feature grid content with five core group sections.
    • SEO dry run: content_update_seo with Rank Math fields.
    • Proposed SEO title: "WordPress Performance Features - PerformWP".
    • Proposed meta description: "Explore PerformWP features for safer WordPress performance work: asset control, page cache controls, cleanup settings, CDN, resource hints, Menu Cache, and WooCommerce optimization."
    • Proposed focus keywords: "WordPress performance features, WordPress asset manager, WordPress performance plugin".
    • SEO dry-run result: status preview, confirmation not required, warnings none.

    Recommended page hierarchy

    1. Page title / H1
    • Change page title from "Features" to "WordPress Performance Features".
    • Keep canonical URL /features/.
    • Goal: make the page self-explanatory in navigation, search, AI citations, and breadcrumbs.
    1. Intro section
    • H2: "Practical controls for faster WordPress pages"
    • Copy preview:
      "Perform helps WordPress site owners, builders, and developers reduce unnecessary front-end work without replacing their whole stack. Use it to control assets, clean up WordPress defaults, tune resource loading, and manage performance-related workflows from a WordPress-native interface."
    • Supporting copy:
      "The goal is simple: make careful, reversible performance improvements with clear controls instead of scattered snippets. Start with the features below, then use the linked docs to configure each setting on your own site."
    • Primary CTA: "Start Optimizing Now" -> https://performwp.com/recommends/perform
    • Secondary CTA: "View Documentation" -> https://performwp.com/docs/
    1. Core performance features
    1. Workflow section
    • H2: "How Perform fits into a performance workflow"
    • Bullets:
      • "Start with measurement. Run a speed test or audit before changing settings so you know which templates, scripts, and third-party resources matter most."
      • "Disable only what you can verify. Use the Assets Manager and cleanup controls in small steps, then test the affected page templates."
      • "Keep cache and CDN changes intentional. Validate dynamic pages, carts, checkout, logged-in views, and forms before expanding cache coverage."
      • "Document the final setup. Keep notes for the next developer or site owner so performance changes are understandable later."
    • Conversion link: "Web Performance Audit" -> https://performwp.com/web-performance-audit/
    1. Proof and trust signals
    • H2: "Proof and trust signals to include"
    • Requirements:
      • Show current WordPress.org metadata: version, tested WordPress version, active installs, rating count, and last updated date.
      • Use current product screenshots from the WordPress.org listing: General Settings, Bloat Settings, Assets Settings, and CDN Settings.
      • Link to WordPress.org and GitHub for install, support, changelog, contribution, and source-code trust.
      • Keep performance language conservative: Perform can help reduce unused work and support Core Web Vitals work, but the page should not guarantee scores or rankings.
    1. Final CTA section

    Design and implementation requirements

    • Use WordPress-native blocks/patterns and the WordPress Design System as the interaction baseline.
    • Use Perform brand blue already present on the site (#0046d1) as the primary accent unless owner provides a fuller brand palette.
    • Do not reuse the current legacy UAGB card copy. The current layout makes each feature look like a disconnected oversized heading on desktop and does not provide enough scan structure.
    • Preferred implementation: constrained intro, compact feature grid/cards, then workflow/proof/CTA sections. Cards should be functional, not decorative, and should not nest cards inside cards.
    • Use product UI screenshots, not generic abstract performance imagery.
    • Capture before/after screenshots on desktop and mobile before any public update is approved.
    • Do not publish the page or change live positioning without owner approval.

    Internal-link requirements

    Owner approval needed

    • Approve public H1/title change from "Features" to "WordPress Performance Features".
    • Approve use of the inferred brand baseline: practical, technical, conservative, WordPress-native, safe-change oriented.
    • Approve cache positioning on the public Features page before page cache docs are public.
    • Approve whether WordPress.org metadata should be displayed as live proof on the page, since active installs/rating counts can drift.
    • Approve publication. Current work is dry-run/spec only.

    Acceptance criteria before publish

    • Public page update is applied only after owner approval.
    • Block validation passes with no core/html.
    • Rank Math title, description, and focus keywords are updated.
    • All internal links resolve to public pages. Draft-only docs are not linked.
    • Desktop and mobile screenshots are captured after implementation and reviewed against the current screenshot.
    • Page copy removes placeholder/repetitive feature descriptions.
    • Performance claims stay conservative and tied to actual shipped behavior.
    • CTA path is visible near the top and bottom of the page.

  6. mehul0810 commented on Oct 3, 2026

    @mehul0810
    mehul0810
    on Oct 3, 2026
    CollaboratorAuthor

    Live recheck for the growth review, 2026-10-03:

    The homepage and Features page have materially improved since the July observations above. They already explain Perform as complementary to an existing performance stack, and the Features page no longer has the old repeated placeholder descriptions. Do not repeat that completed rewrite based on stale evidence.

    Remaining concrete work for this issue:

    • /features/ currently says rules can be applied by post type or template. The reviewed release/1.8.0 source (df4b9983ac565dc01620821172a6fae6d943c186, src/Modules/Assets/AssetsManager.php) contains post-type enable exceptions but no template-rule evaluator; reusable contexts remain open in Expand Assets Manager rule scopes for reusable page patterns #128. Verify the exact shipped behavior and correct/narrow the claim before marketing it as available.
    • /docs/ still presents an archive headed "Archives Docs", with General, Installation, and WooCommerce groups. Surface a version-accurate first optimization guide, Assets Manager, cache boundaries, and undo instructions prominently.
    • The dashboard builds links to /docs/assets-manager/ and /docs/page-cache/. The web reader could not access these destinations in this pass, so their status is unverified, not declared 404. Verify actual HTTP/browser destinations before treating them as working onboarding links.
    • Prioritize one complete task guide and its public demo over a broad article backlog. Existing comparison draft work should be reconciled before creating another article.

    Sources checked: https://performwp.com/ , https://performwp.com/features/ , https://performwp.com/docs/ , https://wordpress.org/plugins/perform/ . This comment records review findings only. No website content was edited or published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: docsDocumentation URLs, help links, readme copy, changelog, or support guidance.area: frontendPublic-facing frontend output, assets, feeds, headers, or visitor behavior.enhancementFeature or improvement request that changes product behavior or user experience.priority: mediumUseful or user-impacting work that should be planned but is not blocking now.status: needs-specNeeds acceptance criteria, scope, UX, or technical design before implementation.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions