Is your WordPress site failing Core Web Vitals? You’re not alone. Google’s performance metrics have become increasingly important for both SEO and user experience, and many WordPress sites struggle to meet these standards.

In this comprehensive guide, I’ll walk you through the exact steps I used to take my site from failing Core Web Vitals to passing—with a focus on fixing the most common culprit: Cumulative Layout Shift (CLS).

Understanding Core Web Vitals

Core Web Vitals are a set of specific metrics that Google uses to measure user experience. The three main metrics are:

Largest Contentful Paint (LCP) measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

Interaction to Next Paint (INP) measures interactivity. Pages should have an INP of 200 milliseconds or less to ensure a responsive experience.

Cumulative Layout Shift (CLS) measures visual stability. Pages should maintain a CLS of 0.1 or less to avoid frustrating unexpected layout shifts.

The Most Common Problem: CLS

After auditing dozens of WordPress sites over the years, I’ve found that CLS is by far the most common reason for failing Core Web Vitals. The primary causes include:

Images without dimensions – When browsers don’t know the size of an image before it loads, the page layout shifts as images appear. This is often the biggest contributor to CLS issues.

Web fonts causing FOUT/FOIT – When custom fonts load, they can cause text to reflow, creating layout shifts.

Dynamic content injection – Ads, embeds, and dynamically loaded content that pushes existing content around.

Third-party scripts – Analytics, chat widgets, and other scripts that modify the DOM after initial load.

The Solution: A Systematic Approach

Rather than randomly trying different optimization plugins, I recommend a systematic approach using a single, well-designed performance plugin. My tool of choice is Perfmatters, but similar results can be achieved with other optimization plugins.

Step 1: Fix Image Loading Issues

The single most impactful change you can make is enabling “Add Missing Image Dimensions” in your optimization plugin. This automatically adds width and height attributes to images that are missing them, allowing browsers to reserve the correct space before images load.

Additionally, enable lazy loading for images and iframes. This defers the loading of off-screen images until users scroll near them, improving initial page load time without affecting CLS (as long as dimensions are set).

Step 2: Optimize JavaScript Delivery

JavaScript can block rendering and delay interactivity. Optimize it by:

Deferring JavaScript – This tells the browser to download scripts in parallel but execute them only after the HTML is fully parsed.

Delaying non-critical JavaScript – Some scripts (analytics, chat widgets) don’t need to run immediately. Delay them until user interaction.

Minifying JavaScript – Remove unnecessary whitespace and comments to reduce file sizes.

Step 3: Optimize CSS

CSS optimization focuses on reducing file sizes and eliminating render-blocking stylesheets:

Minify CSS – Remove whitespace, comments, and unnecessary characters from your stylesheets.

Remove unused CSS – Many themes and plugins load CSS that isn’t used on every page. Removing this unused code can significantly reduce file sizes.

Step 4: Optimize Fonts

Font optimization is crucial for both performance and CLS:

Host Google Fonts locally – Instead of loading fonts from Google’s servers, host them on your own server. This eliminates an external request and gives you more control over font loading.

Use font-display: swap – This CSS property tells browsers to use a fallback font immediately and swap to the custom font once it’s loaded. This prevents invisible text and reduces CLS.

Step 5: Remove WordPress Bloat

WordPress includes several features that most sites don’t need:

Disable emojis – WordPress loads a JavaScript file to convert emoji shortcodes to images. Unless you heavily use emojis, this is unnecessary overhead.

Disable dashicons on the front end – The Dashicons font is loaded for logged-out users even though it’s only needed in the admin area.

Disable embeds – The oEmbed feature allows embedding content from other sites but adds JavaScript that many sites don’t need.

Step 6: Leverage Server-Side Caching

If you’re on managed WordPress hosting like Kinsta, WP Engine, or Cloudways, you already have server-side caching. Make sure to clear your caches after making optimization changes so visitors receive the updated, optimized version of your site.

Measuring Your Results

After implementing these changes, measure your results using:

PageSpeed Insights – Google’s free tool that provides both lab data (simulated tests) and field data (real user metrics from the Chrome User Experience Report).

Web Vitals Chrome Extension – Get real-time Core Web Vitals metrics as you browse your site.

Keep in mind that field data takes 28 days to update fully, so you may see improvements in lab data before they appear in field data.

Additional Optimizations

Once you’ve addressed the fundamentals, consider these additional optimizations:

Use a CDN – A Content Delivery Network serves your static assets from servers closer to your visitors, reducing latency.

Optimize your database – Clean up post revisions, spam comments, and expired transients to keep your database lean.

Audit your plugins – Deactivate and delete plugins you’re not using. Each active plugin adds overhead.

Consider image formats – Modern formats like WebP and AVIF offer better compression than JPEG and PNG.

Conclusion

Passing Core Web Vitals doesn’t require technical expertise or expensive tools. By systematically addressing the common issues—especially CLS caused by images without dimensions—you can significantly improve your site’s performance.

Start with the fundamentals: add image dimensions, optimize JavaScript and CSS delivery, and remove unnecessary bloat. Then measure your results and iterate. With patience and the right approach, your WordPress site can achieve excellent Core Web Vitals scores.

Have questions about WordPress performance optimization? Leave a comment below, and I’ll do my best to help.

After spending over two decades in the WordPress ecosystem — building sites and plugins, running WP Mayor, and watching the platform evolve — I recently found myself asking a question I never thought I’d ask: is it time to look elsewhere?

The question came from an unexpected place. My seven-year-old son wants to build his first website. He’s got ideas — a blog about football, RC cars, retro gaming, places he’s traveled. The kind of personal site that used to be everywhere before social media swallowed the web.

And I found myself hesitating. Do I teach him WordPress, the same way I learned twenty years ago? Or has something better come along — something more modern, more suitable for a beginner in 2025?

It’s a simple question with surprisingly few good answers. And it led me down a rabbit hole that every WordPress developer or agency owner should probably go down themselves.

Drama in the WordPress community is not something new, but the governance drama in 2025 between Automattic and WP Engine hit quite different than previous conflicts, and added urgency to the question. If you missed it: Matt Mullenweg, who controls both Automattic and the WordPress.org infrastructure, got into a public dispute with WP Engine over trademark usage and what he saw as insufficient contribution back to WordPress. It escalated to Automattic blocking WP Engine’s access to WordPress.org plugin updates, effectively weaponizing the shared infrastructure against a major host. Legal action followed.

Whatever you think about the merits of either side, it revealed something uncomfortable: the WordPress ecosystem has a single point of failure. One person’s decisions can disrupt the plugin update mechanism that millions of sites depend on. That’s a governance risk that didn’t feel real until it happened.

It certainly made me think. If the future of WordPress depends on the mood of one person, maybe it’s worth knowing what else is out there.

So I went looking. Properly. Not just a quick Google, but actually evaluating what could realistically replace WordPress for the kind of work most of us do.

I should be upfront about my own position here: I founded and ran WP Mayor for years. I’ve built my career within the WordPress ecosystem for over two decades. I’m not a neutral observer. But that history is also why I take this question seriously — I have skin in the game, and if I’m going to teach my son something, I want it to be the right thing. I’d rather face an uncomfortable answer honestly than keep my head in the sand.

Here’s what I found: nothing.

And that’s actually the story worth telling.

The Landscape Today

WordPress powers something like 43% of the web. That’s not a typo. Nearly half of all websites run on it. When you have that kind of dominance, “replacement” isn’t really the right framing — it’s more like asking what could replace email or the web browser.

But let’s take the alternatives seriously anyway.

Static Site Generators (Astro, Hugo, Eleventy)

These are the darlings of the developer community right now. Astro in particular has real momentum — so much so that Cloudflare just acquired the team behind it in January 2026. You write content in Markdown or HTML, the tool generates static files, and you deploy to Cloudflare Pages, Netlify, or Vercel for free.

The output is blazing fast. No database, no PHP, no security patches. Just HTML files.

The problem? There’s no admin panel. No visual editor. You’re editing files in a code editor and pushing to Git. For developers building their own sites, this is actually pleasant. For clients who need to update their own content? Forget it. You’d spend more time training them than building the site.

These tools aren’t WordPress replacements. They’re developer tools that happen to produce websites.

Modern PHP CMSs (Statamic, Craft, October)

This is where it gets interesting — and then disappointing.

Statamic is built on Laravel and it’s genuinely lovely to work with. Clean codebase, beautiful control panel, flat-file storage option so you can version control everything in Git. If you’re a developer who’s tired of WordPress’s quirks, Statamic feels like a breath of fresh air.

But here’s the thing: Statamic is basically “what if we rebuilt WordPress with modern architecture.” Same concept, cleaner execution. It’s free for solo and hobby projects, but commercial use requires a license ($275+ per site), which adds up quickly if you’re building for clients. The problem is that if you’re going to use something that fills the same role as WordPress, you might as well use WordPress.

That’s a tough sell commercially. It’s like buying a beautifully engineered boutique car when a Toyota does the same job and has mechanics on every corner.

Craft CMS is similar — great developer experience, excellent content modeling, but tiny ecosystem. October CMS tried to be the Laravel-WordPress hybrid and never got traction.

It’s worth mentioning ClassicPress here too — a fork of WordPress that stripped out Gutenberg and aims to maintain a more traditional, stable WordPress experience. If your main complaint about WordPress is the direction of the block editor, ClassicPress directly addresses that. But it inherits the same fundamental limitation as the other alternatives: a much smaller ecosystem. Plugins built specifically for Gutenberg won’t work. The developer community is a fraction of WordPress’s. It’s a viable option for specific situations, but it’s not a path to growth.

None of these are going to grow beyond niche. The network effects aren’t there and probably never will be.

That said, Laravel is currently experiencing something of an AI-driven renaissance. As it becomes easier to build plugins and extensions with AI assistance, I expect more Laravel-based CMS alternatives to emerge, and their marketplaces to fill out quickly. The moat may be collapsing faster than I would have predicted even a year ago.

Headless CMS Options (Strapi, Directus, Sanity, Contentful)

The headless approach separates your content management from your frontend. You store content in a CMS with an API, then build your frontend however you want — React, Vue, static HTML, whatever.

This is popular in enterprise and among developers building complex applications. But for a typical website or blog? It’s overengineered. You now need to build and maintain two things instead of one. And most of these either have usage-based pricing (Contentful, Sanity) or require significant technical overhead to self-host (Strapi, Directus).

Not a WordPress replacement. A different tool for different problems.

Hosted Website Builders (Squarespace, Wix, Webflow)

These took the “I just want a simple website” crowd from WordPress, and honestly, good for them. Someone who would’ve struggled with WordPress anyway is probably better served by Squarespace.

But these are subscription services with limited flexibility. You’re renting, not owning. The moment you want to do something the platform doesn’t support, you’re stuck. And you’re paying monthly forever.

Different market, not a replacement.

The One Exception: Shopify

Here’s where someone actually did take significant territory from WordPress — specifically from WooCommerce.

Shopify succeeded by being opinionated and hosted. You don’t think about servers, updates, security, or plugins conflicting. You just sell stuff. That convenience premium turned out to be worth a lot to merchants who’d rather focus on their products than their technology stack.

If you’re building an e-commerce site today and you’re not a developer, Shopify is often the right answer. That wasn’t true ten years ago.

So Why Does WordPress Still Win?

WordPress’s moat isn’t the technology. The technology is arguably its weakest point — the legacy codebase, the sometimes awkward plugin architecture, the Gutenberg direction that’s divided the community.

The moat is the ecosystem, and at the center of that ecosystem is the plugin directory.

There are over 60,000 plugins in the official WordPress repository, plus thousands more sold commercially. Need SEO tools? Multiple mature options. Need to add e-commerce? WooCommerce and its hundreds of extensions. Need to display your Instagram feed beautifully? Spotlight handles that. Need to aggregate content from RSS feeds across the web? WP RSS Aggregator has been doing that for over a decade. Need membership functionality, booking systems, form builders, multilingual support, backup solutions, security hardening, performance optimization, affiliate management, email marketing integration? Someone built a plugin for it. Probably several someones, so you can choose.

This is the part that newer platforms cannot shortcut. You can build a technically superior CMS in a year or two. You cannot build an ecosystem of tens of thousands of plugins developed over two decades. Every time someone evaluates a WordPress alternative, they eventually hit a feature they need that either doesn’t exist on the new platform or requires custom development. That’s the moment they come back.

Beyond plugins, WordPress has millions of developers who know it, hosting companies offering one-click installs, twenty years of Stack Overflow answers, and a mental model that non-technical people actually understand. And then there’s the educational ecosystem — hundreds of blogs, YouTube channels, and communities dedicated to teaching WordPress for free. Sites like WP Mayor, WPBeginner, and countless others have spent years creating tutorials, reviews, and guides. That depth of learning resources doesn’t exist for alternatives. When you’re stuck at 2am trying to figure out why your site is broken, the answer is almost certainly already written somewhere. Try that with Statamic.

The plugin ecosystem is the killer feature. It’s what lets a non-developer build a genuinely complex site without writing code.

To displace WordPress, you’d need to replicate all of that. Not just build a better CMS, but build an entire ecosystem around it. That takes a decade and a lot of luck.

What About AI?

There’s one wildcard worth considering: could AI change this equation?

The plugin ecosystem advantage exists partly because custom development is expensive and slow. If you need functionality that doesn’t exist as a plugin, you’re either paying a developer or learning to code yourself. That friction pushes people toward platforms with existing solutions.

But AI is making custom development faster and cheaper.

Tools like Claude and Cursor let developers build features in hours that would have taken days. Non-developers are starting to build simple tools themselves with AI assistance. If this trend continues — and there’s good reason to think it will — the “just use a plugin” advantage might erode.

That doesn’t mean WordPress loses. It might mean the opposite: WordPress’s open, extensible architecture could become even more valuable when AI can generate custom plugins on demand. Or it might mean newer, cleaner platforms become more viable because the cost of building missing functionality drops dramatically.

The lines are already blurring. Established WordPress plugins like WP RSS Aggregator are heavily implementing AI features into their existing products. So the question isn’t just “WordPress or something else” — it’s increasingly “WordPress with AI, custom AI-powered apps, or some hybrid we haven’t fully defined yet.”

I don’t know exactly how this plays out. But I’m positioning myself to find out. Through AgentVania, I’m actively helping small businesses implement AI solutions — custom integrations that might eventually become standalone apps, WordPress plugins with AI at their core, or something else entirely. The opportunity feels real, even if the shape of it isn’t fully clear yet.

If you’re thinking about technology choices for the next decade, it’s worth considering that the calculus might shift in ways we can’t fully predict. Staying close to both WordPress and AI seems like a reasonable hedge.

So What Should You Actually Use?

The answer depends on what you’re building. But before getting into specifics, it’s worth stating something clearly: the plugin ecosystem is the real reason WordPress remains dominant. It’s not the core software — the core is showing its age. It’s the fact that whatever you need to do, someone has probably already built a plugin for it. That head start is nearly impossible for newer platforms to overcome.

When you choose a newer CMS with a limited plugin or app collection, you’re betting that either you won’t need extended functionality, or you’re prepared to build it yourself. Sometimes that’s the right bet. Often it isn’t.

With that in mind, here’s how I’d think about specific use cases today:

For a SaaS marketing site — the landing pages, pricing, documentation — WordPress works but is honestly overkill. Astro or another static generator is ideal here: fast, secure, cheap to host, and your dev team can manage it in Git alongside the product code. Many SaaS companies have moved this direction. If you need non-technical marketing people editing content regularly, then WordPress or Webflow make more sense.

For the SaaS application itself — the actual product your customers log into — this is custom application territory. Not WordPress, not any CMS. You’re building with Laravel, Next.js, Rails, or whatever fits your team. The dashboard, the user management, the core functionality: all custom code.

For a blog, whether personal or company, WordPress remains the sensible default. Easy to use, and the SEO plugin ecosystem alone — Yoast, Rank Math, and others — gives you functionality that would take significant effort to replicate elsewhere. If you’re technical and want something minimal, Astro works well. Ghost is worth considering if you want memberships and newsletters built in, though you’re back to subscription pricing for their hosting.

For a brochure site — your typical small business with five to ten pages — WordPress if the client needs to edit it themselves. If it’s truly static and they’ll never touch it, a static generator deployed to Cloudflare Pages or Netlify is simpler and costs nothing to host. Squarespace is honestly fine here too if you don’t want ongoing maintenance responsibility.

For an aggregator site — directories, listings, job boards, content curation — this is where WordPress’s plugin ecosystem genuinely shines. Custom post types, Advanced Custom Fields, and plugins like WP RSS Aggregator let you model complex content relationships and pull in external feeds without building everything from scratch. Try doing that on a newer platform and you’re either writing custom code or discovering the feature simply doesn’t exist. If you need heavy custom functionality beyond what plugins provide, Laravel becomes the better foundation, but you’re committing to building and maintaining everything yourself.

For a dashboard or internal admin panel, never WordPress. This is custom application territory. Laravel with Filament or Livewire works well, or a React/Vue frontend talking to an API. Tools like Retool or Budibase exist if you want a low-code approach.

For e-commerce, Shopify unless you have specific reasons to avoid it — complex customization requirements, wanting to avoid monthly fees, or B2B use cases that don’t fit their model. WooCommerce remains viable if you need full control and can handle the ongoing maintenance burden. The WooCommerce extension ecosystem is massive, which is partly why it’s held its ground against Shopify better than other WordPress-based solutions might have.

For a membership or online course site, WordPress with plugins like LearnDash, MemberPress, or Restrict Content Pro is the established route. The alternatives — Teachable, Kajabi, Thinkific — work well but are subscription-based and lock you into their platform. If you want ownership, flexibility, and the ability to extend functionality with other plugins, WordPress wins. The integration between membership plugins and the rest of the WordPress ecosystem means you can combine courses with WooCommerce, email marketing plugins, affiliate tracking, and more without everything being siloed.

For a forum or community site, WordPress with BuddyPress or bbPress works, though it can feel clunky compared to purpose-built solutions. Discourse is genuinely better for traditional forums but requires separate hosting and management. Circle and similar platforms are subscription-based. Honestly though, for most use cases a private Slack, Discord, or Telegram group has replaced the need for a traditional forum — the format has fallen out of fashion.

For a portfolio site — photographers, designers, creatives showcasing work — WordPress or Squarespace both work well. Squarespace templates are often better designed out of the box for visual portfolios, which matters when the whole point is aesthetics. If the person is technical, a static site with a good gallery setup is cleaner and faster. For Instagram-heavy portfolios, plugins like Spotlight make it easy to display your feed beautifully without manual updates.

For a news or media site, WordPress dominates and it’s not close. The publishing workflow, editorial roles, revision history, scheduling, and the plugin ecosystem for advertising, analytics, paywalls, and newsletter integration are hard to match. Most major online publications run on WordPress or something custom-built with a much larger budget. If you’re starting a media company today, you’d need a compelling reason not to use WordPress.

For a multilingual site, WordPress with WPML or Polylang. This is one area where the plugin ecosystem has an unambiguous advantage — multilingual content management is genuinely complicated, and these dedicated plugins have spent years solving edge cases you’d never anticipate. Building multilingual support into a custom site or using a platform without mature multilingual plugins means rediscovering all those edge cases yourself.

For a landing page or single campaign page, you might not need a CMS at all. A single HTML file deployed to Cloudflare Pages or Netlify, or something built quickly in Webflow or Carrd, is often the right answer. Increasingly, AI tools can generate a complete landing page in minutes — the results are genuinely good now. WordPress is overkill for a one-page campaign that’ll run for three months and then get archived.

The pattern that emerges: WordPress wins when you need a content-managed website that non-technical people will edit, and especially when you need functionality beyond basic content management. The plugin ecosystem means you’re rarely starting from zero. Custom code wins when you’re building an application with unique requirements. Static generators win when it’s developer-managed and performance is paramount. Shopify wins for selling products online to consumers.

So What About My Son?

This brings me back to where I started: what should I teach a seven-year-old who wants to build his first website?

The purist in me considered static site generators. Teach him real HTML, CSS, and JavaScript from the start. No abstractions, no admin panels — just code and a text editor. He’d learn the fundamentals that underpin everything else.

But that’s not realistic for a kid who wants to write about football and share photos from his travels. The friction between “I have an idea” and “it’s live on the internet” needs to be as small as possible. Otherwise the excitement dies before he publishes his first post.

I also considered the hosted builders — Squarespace, Wix, that sort of thing. They’re genuinely easy. But they’re also subscription services that teach you nothing transferable. If he outgrows them, he starts over. And I’d rather he owned his content from day one.

There’s also a more technical approach worth considering: run WordPress locally using Local, convert to static HTML, and publish to Cloudflare Pages via GitHub. The advantage? As long as you keep paying the $10 annual domain renewal, his blog will still be around decades from now — no ongoing hosting fees, no server maintenance, no security updates.

And for simple websites, AI generation is genuinely the fastest way to go now. Tools like Claude’s artifacts can generate a complete, polished website in minutes. Save it to GitHub, publish on Cloudflare Pages or Netlify, done. The results are honestly terrific.

But here’s my hesitation with both approaches: he won’t learn much. The Local-to-static workflow is elegant but opaque — he’d be pushing buttons without understanding what’s happening. And AI-generated sites skip the entire process of building something yourself. The magic of “I made this” gets lost when the honest answer is “AI made this and I clicked deploy.”

So I’m going with WordPress. Not because it’s perfect, but because it hits the right balance for a young beginner:

He can write and publish immediately. The gap between having something to say and saying it publicly is just a few clicks. That immediate gratification matters enormously when you’re seven.

There’s depth when he’s ready for it. He can start just writing posts, then get curious about themes, then maybe peek at the code underneath. The ceiling is high enough that he won’t outgrow it for years — if ever.

The skills transfer. Understanding how WordPress works teaches concepts — content management, databases, hosting, domains — that apply everywhere. Even if he eventually moves to something else, the mental models carry over.

And honestly? I know it. I can help him when he gets stuck, show him tricks, explain why things work the way they do. There’s value in learning something your parent can teach you, beyond just the technical knowledge.

Twenty years later, I’m teaching the same platform I learned on. That says something — either about WordPress’s staying power, or about the lack of alternatives, or both.

What This Means

If you’re a developer or agency wondering whether to jump ship, the honest answer is: there’s nowhere to jump to. Not yet.

If you’re nervous about WordPress governance — and I think that’s reasonable — the practical response is to keep your skills portable. Learn modern PHP and JavaScript. Understand the principles, not just the WordPress-specific implementations. If something does eventually emerge, you’ll be ready.

If you’re building a new site today and you need a CMS with an admin panel that non-technical people can use, WordPress is still the answer. I wish I had something more exciting to tell you.

The gap in the market is real. A modern, open-source CMS with WordPress-level usability and a growing ecosystem would be genuinely valuable. But nobody’s built it yet.

Maybe that’s the opportunity.

---

I’ve spent over a decade in the WordPress world and I’m genuinely wrestling with these questions. What do you think — have I missed something? Is there a platform gaining traction that deserves more attention? Let me know in the comments or reach out on Twitter.

Most developers waste years trying to invent something new.

Top WordPress plugin founders do the opposite: they build in markets that already pay, fix what users hate, and ship fast.

While AI has brought immense changes, other things have stayed the same. The playbook I describe here is the same I’ve used to build WP Mayor, WP RSS Aggregator and SpotlightWP over a span of 15 years.

---

1. Start With a Proven Market — Not an Idea

Forget brainstorming.

Open the WordPress plugin directory and look for plugins with:

• 10k–100k+ active installs
• 3.1–3.9 star ratings (room to improve)
• Freemium or $29–$199/year pricing
• One clear job-to-be-done

Security tweaks, checkout optimizations, performance helpers, SEO utilities, backup tools, form builders — the “boring” categories are where money hides.

If thousands of people already installed it and they’re not fully happy, you have demand.

---

2. Reverse Engineer the Winners

Install the top three competitors and map everything:

• First-run experience
• Upgrade prompts
• Pricing tiers
• Feature gating
• Email flows
• Dashboard layout

Do not improve yet. First understand exactly how money flows.

---

3. Let Bad Reviews Design Your Product

Now read every 1–2 star review.

Paste them into a document and look for patterns:

• “Too expensive” → simpler pricing, clearer value, fewer tiers
• “Confusing interface” → ruthless UX cleanup
• “Missing feature X” → your wedge into the market

Twenty angry reviews will tell you more than months of customer interviews.

---

4. Build the Leanest Possible MVP

Ship only:

• The core workflow
• The onboarding pattern users already understand
• Your 2–3 differentiators

Add the paywall from day one. Avoid “free forever” modes that train users not to pay.

If it takes more than three weeks, you’re not building a business — you’re building a hobby.

---

5. Steal Their Distribution Channels

Your competitors already solved discovery. Find where they live:

• YouTube reviewers
• X threads
• Facebook groups
• Reddit posts
• Niche newsletters

Bookmark everything. Their traffic sources become your traffic sources.

---

6. Launch With Demand Already Mapped

Before launch, your feed should be filled with:

• Plugin comparisons
• “Best WordPress ___ in 2026” roundups
• People complaining about existing tools

You want zero uncertainty about how your market talks, what it values, and what it hates.

---

7. Copy Sales Pages That Convert

Do not write “original” copy from scratch.

Rewrite proven structures:

• Hero promise
• Feature blocks
• Objection handling
• Upgrade CTAs

Same framing, sharper clarity.

---

8. Scale With Affiliates, Not Ads

Once you hit your first few thousand per month:

• Offer 30–50% lifetime commissions
• Recruit bloggers and YouTubers
• Hand them battle-tested angles and copy

One strong affiliate can outperform 100 cold DMs.

---

A Realistic Outcome

A developer cloned a popular image optimization plugin.

Users hated:

• Hidden pricing
• Ugly UX
• Aggressive upsells

He rebuilt the same core with transparent pricing, cleaner UI, and one missing feature users kept asking for.

Three months later: $14k/month.

Total spend: hosting + payment fees.

---

The Rule

WordPress rewards execution, not originality.

Find what already sells. Make it slightly better. Market it relentlessly.

$10k/month is just 250 users paying $40/year.

Not magic. Just disciplined copying.

By default, macOS does not allow you to show the year in the menu bar clock. You can show the day and date, but the year isn’t available.

A simple free workaround is to use BitBar, which lets you run tiny scripts that display text in the menu bar. In this guide, you’ll add a script that shows the full date including the year.

---

Step 1 – Download BitBar

BitBar is free and open-source. Download it from GitHub:

https://github.com/matryer/bitbar

Install it and launch it once. On first run, BitBar will ask you to choose a plugins folder.

---

Step 2 – Choose (or Create) Your Plugins Folder

Use this folder path:

~/Documents/BitBar

If the folder doesn’t exist, create it:

mkdir -p ~/Documents/BitBar

---

Step 3 – Create the Full Date Plugin

Inside your BitBar folder, create a file named:

fulldate.1m.sh

The 1m means the script refreshes every minute.

Open that file and paste this:

#!/bin/bash
date '+%a %d %b %Y'

This will display something like:

Wed 31 Dec 2025

---

Step 4 – Make the Script Executable

Open Terminal and run:

chmod +x ~/Documents/BitBar/fulldate.1m.sh

---

Step 5 – Refresh BitBar

Click the BitBar icon in the menu bar and choose Refresh all.

Your menu bar should now show the full date including the year.

---

Optional: Customize the Date Format

You can change the output by editing the date format string.

European numeric format

date '+%d/%m/%Y'

ISO format

date '+%Y-%m-%d'

Long format

date '+%A %d %B %Y'

---

Optional: Hide the macOS Clock

If you don’t want both the default clock and BitBar showing at the same time:

• Go to System Settings → Control Center → Clock
• Disable Show in Menu Bar

BitBar will then be your single menu bar date display. If your OS does not permit hiding the macOS clock, you can use a third party app like Bartender. Alternatively you can use the option to choose the analog clock, which only shows a discreet analog clock.

---

Position the BitBar Date Instead of the macOS Clock

macOS does not allow third-party menu bar items to occupy the absolute far-right system clock position. However, you can place your BitBar date at the rightmost position of the bar so it behaves visually like the built-in one.

1. Hold the ⌘ Command key.
2. Click and drag the BitBar date item in the menu bar.
3. Drag it all the way to the right until it snaps next to the system clock.
4. Release the mouse.

The BitBar date will now stay anchored in the rightmost position of the bar.