Semrush’s Position Tracking tool is one of the most widely used rank monitors in the SEO world. You feed it a list of keywords, connect your domain, and it checks where you rank every day. Simple premise. But the data it returns isn’t as complete—or as current—as most operators assume.
If you’re basing content decisions, client reports, or traffic forecasts on Position Tracking alone, you’re working with a partial picture. Here’s what the tool actually does, where it breaks down, and how to fill the gaps.
What Position Tracking monitors
Semrush checks your rankings for a predefined list of keywords. You choose the keywords, set a target domain or subdomain, pick a country and device type (desktop or mobile), and the tool runs a daily check. Results appear as a line graph with position changes, estimated traffic, and visibility scores.
It’s useful for tracking a curated set of high-priority terms—your ten core money keywords, your brand terms, the handful of informational queries that drive most of your traffic. If you know exactly what you want to rank for, Position Tracking gives you a clean dashboard.
The tool also flags SERP features: if your keyword triggers a featured snippet, People Also Ask box, or local pack, Semrush notes it. You can filter by feature type and see which queries offer those opportunities.
Where it goes blind
Position Tracking only watches the keywords you tell it to watch. It won’t surface new queries you’re ranking for, seasonal spikes in tangential terms, or long-tail variations that suddenly start converting. If you don’t add a keyword manually, Semrush ignores it.
That’s the opposite of how Google Search Console works. GSC shows you actual queries people used to find your site, even if you’ve never thought to track them. Position Tracking shows you only the keywords you already knew to care about.
The second blind spot: Semrush checks rankings once per day, usually in the early morning UTC. If Google runs a volatile update, shuffles results midday, or personalises rankings based on user context, you won’t see it. The tool reports one snapshot per 24 hours. For stable, evergreen content, that’s fine. For news, trending topics, or anything tied to real-time search behaviour, it lags.
Third issue: Semrush pulls rankings from a standardised environment—no personalisation, no location refinement beyond country-level targeting, no search history. Real users see results shaped by dozens of signals. Position Tracking gives you the cleanest possible view, which is also the least representative.
When to rely on it (and when not to)
Position Tracking works best when you have a short, stable list of target keywords and you want to monitor competitive movement or the impact of on-page changes. If you optimise a product page and want to see whether it moves from position 8 to position 4 over the next two weeks, this tool will catch it.
It’s also useful for client reporting when you need a consistent, branded dashboard. The visibility score and traffic estimates give non-technical stakeholders something to latch onto, even if the numbers are modelled rather than measured.
But don’t use Position Tracking as your primary traffic diagnostic. If organic sessions drop 20% in Search Console, Position Tracking might show no movement at all—because the traffic came from keywords you weren’t monitoring, or because the drop happened outside your tracked keyword set.
And don’t assume the estimated traffic figure is accurate. Semrush models it based on CTR curves and search volume data, both of which are approximations. Actual clicks depend on SERP layout, brand recognition, title appeal, and a dozen other factors the tool can’t see.
How to fill the gaps
Run Position Tracking alongside Google Search Console, not instead of it. Use GSC’s Search Results report to identify which queries are actually driving impressions and clicks, then add high-performers to your Position Tracking list. That way, you’re monitoring the terms that matter, not just the ones you guessed would matter six months ago.
If you’re tracking a large keyword set—say, 500+ terms—set up automated exports or use Semrush’s API to flag significant changes. Manually scanning a long list every day is a waste of time. Build a filter or script that surfaces keywords that moved five positions or more in the last week.
For volatile niches—crypto, trending news, seasonal products—check rankings manually in an incognito window or use a tool like Accuranker that pings results multiple times per day. Semrush’s daily snapshot won’t catch intraday swings.
One non-obvious tip: use Position Tracking’s competitor comparison feature to monitor domains you’re directly competing with for the same keyword set. Add up to five competitors, and Semrush will show you their rankings alongside yours. If a competitor jumps ten positions overnight, you’ll know to investigate their page—they either updated content, built links, or benefited from an algorithm shift. That signal is often more valuable than your own ranking data.
If you found this useful, subscribe to One Two Three Send for weekly breakdowns of the tools and tactics that actually move the needle. We cover the full stack—SEO, email, AI, hosting, monetisation—without the fluff.
Position Tracking is a solid tool. Just don’t mistake its clean, curated view for the messy, comprehensive reality of how search traffic actually lands on your site.
Most solo operators start with one email service provider and route everything through it: welcome emails, password resets, weekly newsletters, product updates, receipts. It’s simple, it works, and for a while there’s no reason to change.
Then something breaks. A welcome email arrives four hours late. A password reset never shows up. Or worse: your newsletter gets a spam complaint, and suddenly all your emails—including order confirmations—land in the promotions tab or get delayed.
The root issue is conflating two fundamentally different types of email: transactional and marketing. They serve different purposes, have different legal rules, and need different infrastructure. Mixing them creates risk you don’t see until it costs you money.
What makes an email transactional
Transactional emails are triggered by a user action and contain information the recipient explicitly requested or needs to complete that action. Examples:
These emails are expected. The user did something, and your system is responding. CAN-SPAM and GDPR treat them differently because they’re not commercial messages—they’re functional infrastructure.
Marketing emails are everything else: newsletters, product announcements, promotional offers, content roundups. They require explicit consent in most jurisdictions, must include an unsubscribe link, and are subject to stricter anti-spam rules.
The line blurs with hybrid emails—like a receipt that also suggests related products—but if the primary purpose is commercial, it’s marketing.
Why reputation matters more than you think
Email service providers (Gmail, Outlook, Yahoo) track sender reputation at the domain and IP level. If you send both transactional and marketing email from the same domain, a single spam complaint on your newsletter can damage deliverability for your password resets.
This is why companies like Stripe and Shopify send transactional email from dedicated domains (receipts come from @stripe.com, but newsletters come from subdomains or separate services). They’re isolating reputation risk.
For solo operators, the practical version of this is: use a dedicated transactional ESP for critical emails. Route your password resets, purchase confirmations, and login links through a service built for speed and reliability. Send your newsletter through a platform optimized for bulk sends, engagement tracking, and unsubscribe management.
Postmark is the gold standard here—transactional-only, no marketing allowed, designed for sub-second delivery. Pricing starts at $15/month for 10,000 emails, and because these are triggered sends (not bulk), most operators stay under 1,000/month. If you’re on WordPress and using a membership plugin or WooCommerce, you’re already generating transactional email. Route it through the right pipe.
When to split your setup
You don’t need two ESPs on day one. If you’re pre-revenue or sending fewer than 100 emails a month total, the complexity isn’t worth it. But you do need to split when:
You’re processing payments or running a membership site (receipts and login emails must arrive instantly)
Your newsletter list is growing past 500 subscribers (spam complaints become statistically inevitable)
You’ve had a deliverability issue with transactional email (password resets delayed, order confirmations in spam)
The cost of a delayed or missing transactional email—lost sale, frustrated customer, support ticket—is higher than the $10–15/month for a dedicated service.
How to route it correctly
If you’re on WordPress, install a transactional plugin (WP Mail SMTP, Postmark’s official plugin, or Brevo‘s SMTP add-on) and configure it to handle system emails. Your membership plugin, WooCommerce, and form notifications should route through this.
Your newsletter platform (Beehiiv, MailerLite, ConvertKit) handles everything else: weekly sends, product launches, content updates. These platforms are built for engagement tracking, A/B testing, and list segmentation—features you don’t need (and don’t want) in a password reset.
If you’re not on WordPress, check your app’s email settings. Most SaaS tools let you configure SMTP credentials. Point transactional sends to your transactional ESP, and keep marketing sends in your newsletter tool.
One non-obvious tip: set up separate subdomains. Send transactional email from mail.yourdomain.com and newsletters from news.yourdomain.com. This isolates reputation at the DNS level and makes it easier to debug deliverability issues later.
If you’re routing everything through one service today and haven’t had a problem yet, you’re not wrong—you’re just early. But when you hit the threshold where mixing email types starts costing you conversions, you’ll know exactly what to fix.
Got a question about your email setup? Reply to this email—I read every message and often turn answers into future pieces.
Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.
Claude introduced prompt caching in late 2024, and most solo operators still don’t use it — even when they’re burning through API credits on repetitive tasks.
The feature lets you cache large chunks of context (style guides, product catalogs, documentation) so Claude doesn’t re-read them on every request. When it works, it cuts costs by 90% and speeds up responses. When it doesn’t, you pay a caching penalty for no benefit.
Here’s how to know which side you’re on.
How prompt caching actually works
Every time you send a prompt to Claude, the API charges you for input tokens (what you send) and output tokens (what Claude generates). With caching enabled, Claude stores the first part of your prompt — the part that doesn’t change between requests — and reuses it for up to five minutes.
Cached input tokens cost 90% less than regular input tokens. But there’s a catch: the cached section must be at least 1,024 tokens, and it has to appear at the start of your prompt. If your repeated context is buried mid-prompt, caching won’t trigger.
Most operators structure their prompts backwards. They put the variable part (the user question, the draft to edit, the product name) first, then append the static instructions. That ordering breaks caching.
To make caching work, flip it: static context first, variable input last.
When caching saves real money
Caching pays off when you’re running the same large prompt dozens or hundreds of times per day. Three scenarios where it matters:
Batch content editing. You’re rewriting 50 product descriptions using the same brand voice guide (3,000 tokens). Without caching, you pay full price for that guide on every request. With caching, you pay once, then 10% for the next 49.
Structured data extraction. You’re parsing invoices, receipts, or support tickets into JSON using the same schema definition (2,000 tokens). Each parse job reuses the schema. Cache it.
Context-heavy chat interfaces. You’re building a support bot that references your entire help center (10,000 tokens) on every question. Cache the help center, send only the user’s question as new input.
If you’re running fewer than 10 requests per day with the same context, caching won’t move the needle. The setup overhead isn’t worth it.
How to structure prompts for caching
Here’s the wrong way (no caching):
User question: [variable input] Instructions: [3,000-token style guide]
Here’s the right way (caching triggers):
Instructions: [3,000-token style guide] User question: [variable input]
In the API request, you mark the instructions block as cache_control: {"type": "ephemeral"}. Claude caches everything up to that marker. On the next request, if the cached section is identical, you pay the reduced rate.
One non-obvious detail: the cache expires after five minutes of inactivity. If your workflow runs requests in bursts with long gaps, you’ll pay the caching write cost repeatedly without ever hitting the cache. Caching works best for sustained, high-frequency use — not sporadic jobs.
When caching costs more than it saves
Caching isn’t free. The first time Claude writes to the cache, you pay a 25% premium on those tokens. If you send a 5,000-token prompt once and never reuse it, you’ve paid extra for nothing.
You also lose caching benefits if you tweak the cached section between requests. Changing even one word in your style guide invalidates the cache and triggers a new write. If you’re still iterating on your prompt structure, wait until it’s stable before enabling caching.
And if your repeated context is small (under 1,024 tokens), caching won’t activate at all. The feature is designed for large, static blocks — not short instructions.
What this means for your workflow
Most solo operators should ignore caching until they hit a clear threshold: same large prompt, 20+ times per day, stable structure. Below that, the cost savings are negligible and the cognitive overhead of restructuring prompts isn’t worth it.
But if you’re running batch jobs, building repeatable AI workflows, or prototyping a product that calls Claude hundreds of times, caching can cut your API bill in half. Just don’t bolt it onto your existing prompts without restructuring them first.
Using Claude for high-volume workflows?Subscribe to One Two Three Send for more breakdowns of AI features that actually matter to solo operators.
Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.
If you’ve decided Google Analytics is overkill—or you just want to stop dealing with cookie banners—you’ve probably narrowed your shortlist to Plausible and Fathom. Both are privacy-first, cookieless, and built for operators who want clean dashboards instead of data warehouses.
But they’re not interchangeable. One prioritises speed and price. The other prioritises polish and brand positioning. Here’s what matters when you’re deciding where to send your $14–$24 per month.
Pricing: same until you scale
Both charge based on monthly pageviews, and both start at $14/month for up to 10,000 pageviews.
Plausible: $14/mo for 10k pageviews, $24/mo for 100k, $69/mo for 1M. Annual billing gets you two months free.
Fathom: $15/mo for 100k pageviews (yes, 10× more volume at nearly the same price), $25/mo for 250k, $55/mo for 1M. Discounts for annual.
At low volume, they’re equivalent. Once you cross 50,000 pageviews per month, Fathom becomes meaningfully cheaper. If you’re running a single content site doing 200k pageviews a month, Fathom saves you $100+ per year.
But if you track multiple properties—say, a main blog, a documentation site, and a landing page—Plausible’s $14/mo entry tier can feel punitive. You’ll pay per site unless you consolidate under roll-up reporting (more on that below).
Interface and speed
Plausible’s dashboard loads faster. That’s not subjective—it’s lighter on JavaScript and renders in under a second on most connections. The layout is spartan: one page, collapsible cards for top sources, pages, countries, devices. No tabs, no sub-navigation.
Fathom’s interface is more polished. It has tabs for current visitors, uptime monitoring (included free), and event funnels. The design feels more considered, but it’s also heavier. On slower connections or mobile, you’ll notice the lag.
If you check analytics daily and want instant feedback, Plausible wins. If you check weekly and want a bit more UI personality, Fathom feels nicer to open.
Features: where they diverge
Both handle the basics—pageviews, referrers, devices, goals, custom events. But the extras differ.
Plausible includes email reports (daily, weekly, monthly), shared dashboards, and Google Search Console integration. It also offers a self-hosted option if you want to run your own instance (starts at $0 for self-hosters, but you handle the server).
Fathom includes uptime monitoring (checks your site every 30 seconds from multiple regions), EU isolation (useful for GDPR-strict clients), and better event funnel visualisation. It also lets you import historical Google Analytics data, which Plausible doesn’t.
Neither tool offers heatmaps, session replay, or A/B testing. If you want those, you’re looking at Hotjar or Microsoft Clarity (free, privacy-questionable) as a separate layer.
Roll-up reporting and multi-site operators
Both let you combine multiple properties into one dashboard, but the UX differs.
Plausible calls this “roll-up reporting.” You pay for total pageviews across all sites, but you can view aggregate stats or drill into individual properties. It’s clean, but the setup requires manually grouping domains.
Fathom doesn’t have native roll-up views. You track each site separately and flip between them in a dropdown. If you want combined stats, you export CSVs and merge them yourself. For operators running 5+ properties, this gets tedious fast.
When to pick Plausible
You’re starting out and want the lowest entry price for a single site.
You value dashboard speed and minimal UI chrome.
You want Google Search Console integration baked in.
You’re open to self-hosting (or already run your own infrastructure).
When to pick Fathom
You’re doing 100k+ pageviews per month and want better per-pageview pricing.
You need uptime monitoring without adding another tool.
You want to import your GA history before making the switch.
You prefer a more polished interface and don’t mind the weight.
What neither tool solves
Both are great if you want top-line traffic numbers and respect visitor privacy. But if you need user-level attribution—knowing which blog post led to a purchase three weeks later—you’ll need something heavier. Fathom and Plausible don’t track users across sessions. That’s the tradeoff for being cookieless.
If you monetise via ads, neither integrates with ad networks. You’ll still need Google Analytics or a dedicated ad analytics layer. If you monetise via products or subscriptions, you can wire custom events to both tools and get conversion counts—but you won’t get cohort analysis or LTV breakdowns.
For most solo operators and small content teams, that’s fine. You’re not optimising funnels at scale. You just want to know what’s working.
Want more tool breakdowns like this? Reply and tell us which category you want compared next—hosting dashboards, AI writing assistants, or social schedulers all qualify.
Most of what gets written about the Facebook algorithm is wrong, or at least useless. Posting time does not meaningfully matter. Hashtags do not move the needle the way they used to. Caption-tweak hacks are noise. What actually drives whether your post gets seen by 200 people or 200,000 is a small set of mechanics that have been publicly described by Meta engineers and confirmed by years of outlier data. This post walks through those mechanics and what they imply for how you should actually be posting.
If you run a Facebook Page and care about reach, this is the framework worth understanding — and at the end we will get into why doing this consistently is the actual hard part, and how One Two Three Post Pro closes that gap.
What the algorithm actually does when you post
Facebook (and Instagram, and TikTok, and the rest) has exactly one business goal: keep users on the platform as long as possible. The longer someone scrolls, the more ads they see. That is the whole equation. Every algorithmic decision flows from it.
To maximise scroll time, the algorithm acts as a matchmaker. It tries to put the post most likely to delight a given user in front of that user, while not delighting them so much they screenshot it and leave. When you publish a new post, the platform runs a multimodal analysis on it within seconds: computer vision over the image or video, audio fingerprinting on any sound, plus all the metadata it has — your caption, your Page history, the time and geography, whether the post mentions other accounts, whether it links externally. All of that rolls into a single internal representation of “what is this post about and who is likely to enjoy it” — call it a topic mapping.
Based on that topic mapping, the algorithm builds a prediction: which users currently active on Facebook are the best fit for this post. That prediction is a ranked list of every active user. The top of the list — roughly 200 people — becomes the initial sample group.
The 200-person sample group is where the post lives or dies
This is the single most important thing to understand about how Facebook works in 2026: most of the people who see your post first are not your followers. The algorithm deliberately seeds new posts to a sample group that is overwhelmingly weighted toward strangers — accounts that fit the topic-mapping profile but have not opted into your Page. The reason is calibration. Your followers are biased: they already like you, so their engagement signal is noisy. Strangers are honest. If a stranger watches, likes, and shares a post, that is genuine algorithmic gold. If 200 strangers shrug, the post is not actually as good as your follower count would suggest.
What happens next depends entirely on how that initial 200 responds:
Strong engagement from the sample group → the algorithm boosts to roughly 2,000 next, then 20,000, then 200,000, scaling up in 10× steps until the data finally thins. This is the path that produces a viral post.
Mixed engagement → the algorithm refines its fit-score, picks a fresh sample of 200 with a slightly different profile, and tries again. You might never see the second sample reflected in your view count because it happens within minutes of publishing.
Weak engagement → the algorithm stops promoting almost immediately. The post stalls at “200 view jail” and never recovers, no matter how good it actually is.
This is why two posts on the same Page can have wildly different reach. The one that landed well with its 200-person sample scales to 50,000 views. The one that did not stays at 180.
Two posts on the same Page can have wildly different reach. The one that landed well with its first 200 scales 10× at every step. The one that did not stalls under 200 views.
The two levers you actually have
If the sample group is the choke point, there are only two things to optimise: help the algorithm find a tight, accurate sample group in the first place, and make sure that group has a strong reason to engage when it sees the post.
Lever 1: Narrow your topic and audience, ruthlessly
The algorithm builds its fit score for your fourth post by looking at how the first three performed. If post one was about tech, post two about health trends, and post three about politics, the algorithm has no idea what post four is about — so it builds a blended sample group made up of strangers from all three audiences. When post four turns out to be about health trends again, two-thirds of the sample group did not want it, the engagement comes back weak, and the post flops. Even though it was the right post for the right audience, the blended sample failed it.
The fix is unglamorous: pick one audience and one tight band of topics, and stay there for months. Every post you publish that is off-topic costs you the next several on-topic posts in algorithmic confidence. The discipline matters more than the topic. A Page that has posted about Edinburgh hidden gems three hundred times in a row gets a sample group of strangers who like Edinburgh hidden gems. A Page that posts about Edinburgh, then about generic UK travel tips, then about a personal life update, gets a blended sample group that engages weakly with all three.
The algorithm builds the next post’s sample group from the last few posts. Mix the topics and you get a mixed sample that engages with none of them strongly.
On Facebook specifically, this discipline is hard because the natural temptation is to mix in a quick newsletter promo, a behind-the-scenes shot, or a “Just sharing this!” link whenever you remember. Each off-topic post knocks the algorithm’s calibration loose for the next several real posts. The cleanest fix is to commit ahead of time to a small set of content types and rotate through them mechanically, not opportunistically.
Lever 2: Make the sample group engage
Once the right 200 strangers are looking at your post, three metrics decide whether the algorithm boosts:
Watch time and percent-completion for video; equivalent dwell time on text posts (how long the post stays on screen before the user scrolls past).
Engagement rate — likes + comments + shares + saves divided by views. Comments are weighted heaviest because they cost the most user effort.
Session share — what fraction of a given user’s 60-minute Facebook session is spent on your content. You cannot see this number in any dashboard, but Meta engineers have confirmed it is the most influential of the three. A Page whose readers stick around to read more of its posts gets boosted; a Page that gets a single like and then loses the reader to a competitor’s post does not.
Of those three, engagement rate is the one operators have most direct control over. And on Facebook, two formats consistently outperform on engagement rate:
Native coloured-background text posts. Facebook gives these visual punch in the feed that a plain link post or even a photo post does not match. Coloured-background posts are statistically more likely to stop a scroller mid-flick, which improves dwell time, which improves the algorithm’s read of the sample-group response.
Open-ended questions in the caption that invite replies. Comments are the highest-value engagement signal, and the easiest way to drive comments is to ask something the reader actually wants to answer.
If you want to push comments specifically, a few principles work reliably:
Take a clear stance. Hedged, “on the one hand, on the other hand” captions produce nothing. People comment when they agree forcefully or disagree forcefully. Pick one.
Lean slightly contrarian. If your stance is the consensus view, no one needs to argue. If it is a minority view, the majority feels compelled to push back.
Amplify the framing. “This is the best way to cook pasta” gets a polite nod. “Every Italian grandmother is doing this wrong” gets an argument in the comments.
Anchor around cult-loved brands, people, or ideas. Pre-formed opinions trigger faster engagement than novel categories. A post about Nike will out-comment a post about “shoes”.
Drive emotion. Outrage, nostalgia, joy, surprise — any of them work. Neutral does not.
And on the link side: do not put external links in the post body. Facebook downranks posts that try to send users off-platform — the algorithm reads them as “this person wants the user to leave, which is the opposite of our goal”. Put the link in the first comment instead. The algorithm does not penalise comments the way it penalises link cards.
Facebook treats a link in the body as “this user wants to leave the platform” and dampens reach. The same link, posted as the first comment after publish, is invisible to that filter.
The gap between strategy and execution
None of the above is secret. Operators who care about Facebook reach already know these mechanics. The reason most Pages still fail is not strategy — it is execution. If you write out what running the strategy looks like on a Tuesday afternoon, the to-do list is brutal:
Pick two or three content types and stay rigidly inside them for months.
Post at least once a day, ideally for the next year, without missing a day.
Rotate the types so you never post two of the same type back to back (three identical-type posts in a row reads to the algorithm as a stale account).
Space posts out so they do not bunch up in a single hour (the algorithm reads bursty publishing as low-quality account behaviour).
Use native Facebook formats wherever possible — coloured-background text posts, not link cards.
Put any external link in the first comment, never the post body.
Vary the question prompts so the engagement format does not feel scripted.
Catch your own mistakes before publishing — an AI-named image filename, a duplicate caption recycled from three weeks ago, a brand mention you forgot is on the Facebook ban list, a winter post you scheduled in October that is about to fire in July.
Read that list again. That is roughly 90 minutes of weekly admin work, every week, forever, before you have written a single line of content. The reason most operators drift back into “post whatever, whenever” is not that they disagree with the strategy. It is that the discipline is incompatible with doing the rest of their actual job.
How One Two Three Post Pro automates the operational layer
One Two Three Post Pro is a WordPress plugin that sits on top of the free One Two Three Post scheduler. It is built around the assumption that you have a WordPress site with blog content and you need that content to keep your Facebook Page running on the algorithm-friendly cadence above. Walking through the list:
Three content types, automatically rotated
Pro auto-generates posts in three formats — only three — chosen specifically because they map to what Facebook’s algorithm rewards:
Photo posts from your recent blog posts. The featured image plus a short caption that links the reader back to the article. The link goes in the first comment, not the body. This is the consistent-topic workhorse — every photo post is tied to your existing content, so the topic mapping the algorithm builds for your Page stays tight.
Text questions as native coloured-background text posts. These are the engagement-rate accelerator. The plugin ships a starter pool of 20 open-ended questions you can edit, and falls back to Claude (if a key is configured) to write fresh ones when the pool runs dry. Open-ended questions reliably outperform plain photo posts on comment rate, which directly improves the 200-sample engagement signal.
Newsletter teasers as native coloured-background text posts with the signup link in the first comment. Punchy curiosity-gap hooks like “Stories the guidebooks won’t tell you, fresh in our inbox”. Capped at 1 per day so the format does not start looking like spam.
You configure the ratio between the three (default 50/25/25 photo/question/teaser) and Pro picks weighted-randomly on each cron tick. The output is a steady stream of varied native Facebook posts on a narrow avatar — exactly what the algorithm uses to lock in a strong fit score.
Cadence held by an hourly cron
Pro’s content auto-fill cron runs hourly and tops your queue up to a target depth (default 12 scheduled posts in the next 24 hours). On a quiet hour it adds one new post; on full hours it adds nothing. The result is a steady cadence you do not have to think about. Set the target depth, walk away, come back in a week to find 84 posts have queued and fired automatically.
Type rotation + spacing validators
Two pre-publish validators directly address the algorithmic-confusion problem above:
Type rotation blocks a queued post if the last N published posts were all the same type. Stops the “three photo posts in a row” scenario that flattens the algorithm’s fit score.
Minimum spacing blocks a queued post if another post on the same Page fired within the last N minutes (default 60). Stops bursts that the algorithm reads as low-quality account behaviour.
Both are toggleable, configurable, and silent when nothing is wrong. When they do block, the post is held in pending with the reason logged so you can adjust or wait for the window to clear.
Five more validators catching the “stranger bounces” issues
The 200-view jail happens when the sample group sees something off about the post and skips it. Pro’s other validators catch the most common off-putting issues before the post fires:
AI-generated image filenames (Facebook is increasingly aggressive about flagging AI imagery — easier not to invite the suspicion).
Duplicate images via perceptual hashing — the algorithm sees the same picture three weeks in a row and downranks for repetition.
Duplicate captions — same problem, different vector.
Seasonal mismatches — a snow post in July reads as scheduled-and-forgotten content, which tanks the sample group’s reaction.
Banned-word matches — keep brand-safe terms out of the caption before Facebook’s own filters quietly nerf the reach.
First-comment auto-detection
If a queued post’s caption mentions a recent blog post’s title, or matches a configured category keyword, or contains a curiosity-gap teaser phrase like “have you heard…”, Pro auto-fills the corresponding WordPress permalink as the first comment. Operator-set values are never overwritten. This keeps every post link-free in the body, where the algorithm wants it.
Editor pass every six hours
Six times a day, Pro re-runs the validator chain against everything scheduled to fire in the next 24 hours. If a validator would block at publish time, the post is moved to pending immediately so you see the problem hours before the fire window. Avoids the “scheduled post failed at 06:00 because I posted something similar last night” pattern.
The honest summary
The strategy for winning on Facebook in 2026 is well-known: post consistently on a narrow avatar with formats the algorithm rewards, give the 200-person sample group a reason to engage, and keep external links out of the post body. The hard part is sustaining that behaviour for the 12 months it takes to compound. Most Pages do not fail because the operator does not understand the algorithm — they fail because operating it manually is a part-time job, and the part-time job loses to whatever else is on the calendar.
One Two Three Post Pro reduces that part-time job to: install the plugin, set the queue target, pick your content-type ratios, walk away. Posts auto-generate from your blog. Validators stop the algorithmically-bad ones from firing. The editor pass catches problems before they happen. First-comment links keep Facebook from downranking you for sharing external URLs. The cadence stays steady whether you are at your desk that week or on holiday.
WordPress multisite lets you run dozens of sites from a single installation. One codebase, one database, one update cycle. For operators managing a network of niche content sites, course platforms, or regional brands, it sounds like the obvious move.
But multisite isn’t just “WordPress with more sites.” It’s a fundamentally different architecture—and once you’re in, migrating out is painful. Here’s how to decide whether it fits your business model, and what breaks if you get it wrong.
What multisite actually changes
In a standard WordPress setup, each site lives in its own directory with its own database. Multisite flips that: one WordPress core, one shared wp-content folder, and a single database with prefixed tables for each site.
You can create new sites in seconds. Every site inherits the same plugins and themes (unless you network-activate selectively). Updates happen once, across the entire network. If you’re running ten sites and need to patch a security flaw, you do it once instead of ten times.
The tradeoff: every site shares the same server resources, the same PHP version, and the same plugin environment. If one site gets hammered with traffic, the others slow down. If a plugin conflicts on site three, it can break site seven. And if you ever want to spin one site off into its own hosting account, you’ll need a multisite-to-single-site migration tool and a few hours of downtime.
When multisite makes financial sense
Multisite shines when your sites are similar in purpose and traffic profile. If you’re running a portfolio of niche affiliate blogs—say, five sites covering different hobbies, all using the same theme and monetisation stack—multisite cuts hosting costs and eliminates redundant maintenance.
A single VPS at BigScoots can comfortably handle a multisite network of ten low-to-mid-traffic sites for around $50/month. Running those same sites on individual shared hosting accounts would cost $10–15 each, or $100–150 total. You also skip the pain of logging into ten dashboards to update plugins every week.
Multisite also works well for franchise models or regional content networks. If you’re publishing city-specific restaurant guides and every site needs the same review template, event calendar, and ad slots, multisite keeps everything in sync without custom deployment scripts.
When it becomes a liability
Multisite falls apart when sites diverge. If site A needs WooCommerce, site B runs a membership plugin, and site C is a static brochure, you’re stuck managing plugin compatibility across three different use cases on one shared stack.
Performance isolation is another problem. Multisite has no built-in resource limits per site. If one site goes viral or gets scraped by a bad bot, it can starve the others of CPU and memory. You’d need server-level controls (like cgroups or container isolation) to prevent one site from taking down the network.
And if you ever want to sell a site, multisite complicates the deal. Buyers expect a standalone WordPress install they can move to their own hosting. Extracting a single site from a multisite network requires exporting the database tables, remapping file paths, and reconfiguring domain settings—doable, but not trivial.
One non-obvious tip: subdirectory vs. subdomain structure
When you create a multisite network, WordPress asks whether new sites should use subdomains (site1.example.com) or subdirectories (example.com/site1). This decision is permanent without a full reinstall.
Subdirectories are simpler—no DNS changes, no wildcard SSL setup. But they limit you to one root domain. If you want each site to eventually have its own domain, start with subdomains (or use domain mapping from day one). Most managed hosts, including BigScoots, support wildcard SSL out of the box, so subdomain setup is usually friction-free.
If you’re running a true multi-brand network where each site needs its own identity, map custom domains from the start using the built-in domain mapping feature (or the WordPress MU Domain Mapping plugin on older installs). Don’t rely on subdirectories and assume you’ll migrate later—it’s messier than it sounds.
The breakpoint
Multisite makes sense when your sites share DNA: same theme, same plugins, similar traffic, and a long-term plan to keep them together. It saves money and time at scale.
But if you’re experimenting with different business models, expect uneven growth, or might sell individual properties, the operational flexibility of separate installs is worth the extra cost.
The worst outcome is committing to multisite for cost savings, then realising two years in that you need to split everything apart. Run the numbers on hosting and maintenance time, and decide which architecture matches where your business is heading—not just where it is today.
What’s your experience with multisite? Hit reply and let us know whether it simplified your workflow or became a bottleneck. We read every response.
Last week Ali Abdaal published a 14-minute video called How to Start an Email Newsletter. It is a good primer: why a newsletter is the easiest creator project to start, what to write about when you have no idea what to write about, and a three-platform walkthrough at the end (ConvertKit, Revue, Substack).
The first two-thirds hold up perfectly. The third-act platform recommendation is where we want to add something. Revue closed in 2023. Substack still works but it owns the relationship between you and the people who read your writing. There is a better default in 2026: write the newsletter on your own WordPress site using a free plugin, and you keep the subscriber list, the email addresses, the design, and the URL forever — even if you change tools next year.
This is that walkthrough.
Part 1: Why you might want a newsletter in the first place
Ali makes five arguments, and they all stand up:
It is free to start. Unlike a YouTube channel — which needs at least a phone, decent lighting, and the courage to film yourself talking to no one — a newsletter is just an email. You type, you send. There is no production setup.
It is low-friction. Most people who freeze when starting a creator project freeze because the first step is hard. With a newsletter the first step is “write a paragraph and click send”. If you can write a long text message you can write a newsletter.
It is private until you want it to be public. There is no algorithm pushing your newsletter into anyone’s feed. Your first ten issues can go to your mum and one friend and that is fine. You get to practice the craft of writing for an audience before there actually is an audience. YouTube does not give you that grace period.
You own the audience. An email address is the closest thing the internet has to a direct line. The reader has explicitly given you permission to show up in their inbox, and you can unsubscribe with one click — which means anyone who stays is choosing to be there every single week. That is much more valuable than a follower count on a platform that can change its algorithm tomorrow and bury your work.
It can become an asset. Ali wrote his Sunday Snippets newsletter for three and a half years before he made any direct money from it. Now individual sponsor slots go for $5,000–$7,000. Morning Brew started as a daily email written by Alex Lieberman in his university dorm room; five years later he sold it for $70 million. The point is not that your newsletter will sell for $70 million. The point is that a newsletter that nobody pays for today can quietly become a real business in three years, without you having to bet your career on it now.
Part 2: What to write about (or: the only question that actually stops people)
The wall most people hit is not “I do not know how to type”. It is “I do not know what I would even write about”. Three responses to that:
Write about whatever you find interesting. If you genuinely enjoy writing Harry Potter fanfiction, write three paragraphs of Harry Potter fanfiction every Sunday. The reason this matters is not the topic — it is that intrinsic motivation is the only thing that keeps you consistent in the first year, when nobody is reading. Consistency is the secret. If you are doing it for the love of the craft, you keep going. If you are doing it for the money, you quit when the money does not appear by month three.
Curate. Tim Ferriss runs one of the largest newsletters in the world — Five Bullet Friday — and the entire format is “five things I enjoyed this week”. A book, a podcast, a gadget, an article. You almost certainly consume stuff during the week that other people would benefit from. Send them a list.
Pick a topic. Morning Brew is just “what’s happening in business and tech, told entertainingly, every weekday morning”. If you are genuinely interested in something, there are almost certainly other people who would like to be kept up to date on it without having to find the sources themselves.
All three work. None of them require you to be an expert. They require you to write the thing every week.
Part 3: How to actually start one — without giving the platform a permanent cut
Here is where we depart from Ali’s video. He recommends Substack as the default for someone starting from scratch. Substack is fine for a first draft, but it has two long-term problems:
10% of every subscription, forever. The moment your newsletter starts making money, Substack takes 10% off the top. On a healthy paid newsletter that is real money — a thousand subscribers at $8/month is $9,600 a year going to a platform you do not need by year two.
It is their URL, their design, their brand. Your newsletter lives at yourname.substack.com with their header, their fonts, their suggested-newsletters block at the bottom of every email. Migrating off later is possible — but you lose a lot of the SEO and brand equity you have built.
The alternative: run your newsletter from a WordPress site you already own, with a plugin called One Two Three Send. Free, no revenue share, no platform lock-in, no algorithm-driven sidebar. Your domain, your design, your subscriber list — yours in the literal sense that they live in a database table on your own host.
Five minutes from zero to a sent newsletter
Install the free plugin. WordPress admin → Plugins → Add New → search “One Two Three Send” → Install → Activate. Or grab it directly from wordpress.org/plugins/one-two-three-send.
Pick how emails actually get sent. Newsletter → Settings → Email Provider. Resend (free for first 3,000 emails/month, simple API key paste) or SMTP (any provider including Amazon SES, MailerLite, Brevo, Mailchimp). Pick one, paste credentials, save.
Drop a signup form somewhere. Newsletter → Signup Forms gives you a default form on first activation. Embed it on your homepage with , or use the Gutenberg block. Done.
Write the first issue. Newsletter → New Newsletter. Type something. Click Run audit (the plugin checks the obvious mistakes — missing unsubscribe link, dodgy subject line length, broken placeholders, spam triggers). Click Send.
Your first subscriber is you. Add your own email through the Subscribers tab so you can see what arrives. Send the first issue. Open it. Forward it to your mum.
That is the entire free plugin. It is enough to run a real newsletter for as long as you want. The whole “I do not know what platform to start on” friction goes away because you are writing inside the same WordPress admin you would use to write blog posts.
When you outgrow the free tier
Ali talks about the moment a newsletter starts to make money — sponsors, a course, a paid tier. That is the moment Substack quietly starts charging you 10%. With One Two Three Send the upgrade path is a companion plugin called One Two Three Send Pro, distributed to subscribers of our own newsletter. What it adds maps directly to the use cases Ali mentions in the video:
Stripe paywalls for paid subscribers, with no revenue share to anyone. You set the prices, Stripe charges, the money goes to your bank account. We see the metadata to flip the free/paid flag on a subscriber row; we never see the payment itself.
AI newsletter generator using your own Claude API key. This is the practical answer to “what should I write about this week” — Claude drafts from your site’s recent posts, your tagline, and a manual description of your voice. You edit. You send. The cost per issue is a few cents of Claude tokens, paid directly to Anthropic.
Welcome email + lead magnet delivery on every signup, completely automatic. A new subscriber gets a personalised “thanks for signing up, here is your free PDF” email within seconds of the form submission.
More email providers — Mailchimp, MailerLite, Brevo, ConvertKit, Amazon SES on top of Resend and SMTP. Pick the one your audience already trusts.
Newsletter Network — opt-in cross-promotion ring of other One Two Three Send sites. Drop a small widget on your blog posts, your readers see other newsletters, their readers see yours. It is the closest thing to an algorithm a self-hosted newsletter has, and it costs you nothing except the screen space at the bottom of a blog post.
Pre-send audit with five extra Claude-powered checks on top of the free plugin’s ten — tone match, opening hook, structure, call-to-action strength, subject-vs-body alignment. Catches the issues that make sends embarrassing in retrospect.
The pricing model for Pro is intentionally simple: it is bundled with the paid tier of the publication you are reading right now, so there is no separate marketplace, no separate licence key, no separate billing. See pricing if you are curious.
The honest summary
Ali’s video is right about the why and right about the what. The free plugin we make is just a different answer to the how — one where the subscriber list, the URL, the design, and the future revenue all belong to you, and the only thing we ever bill you for is the optional Pro upgrade that does not change who owns the relationship.
If you watched the video and felt the itch to start, do not over-think the platform decision. You can start on Substack tonight and migrate later if it works out — we have a CSV-import path that takes ten minutes. Or you can start on your own WordPress site tonight and skip the migration entirely. Either way, the part that matters is writing the first issue this week.
Hit reply on any of our issues once you have sent yours. We read every one.
Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.
Gumroad’s variant pricing feature lets you offer multiple versions of the same product—different formats, license tiers, or access levels—without duplicating product pages. A single URL can serve a $9 PDF, a $49 video bundle, and a $199 commercial license.
The mechanic is simple: buyers see a dropdown or radio buttons before checkout. Pick a tier, click buy, done.
In practice, it’s more nuanced than that. Variants can increase average order value when implemented well, or create decision paralysis when overdone. The difference comes down to how you structure the choice and what you’re actually selling.
How Gumroad’s variant pricing actually works
When you create a product in Gumroad, you can add variants under the pricing section. Each variant gets its own name, price, and optional description. You can also attach different files to each variant—so a “basic” tier delivers a PDF, while a “pro” tier adds video files and templates.
Gumroad handles fulfillment automatically. The buyer selects a variant, pays, and receives only the files attached to that specific option. You’re not manually sorting orders or sending different download links.
The feature supports up to 100 variants per product, though you’ll never need that many. Most successful Gumroad creators use two to four.
Variants appear on your product page as a selection interface. You control the display style—dropdown menu, radio buttons, or cards with images. The card layout works best for visual products where the difference between tiers is obvious at a glance (e.g., template packs with different color schemes). Radio buttons work for straightforward upgrades like “personal use” vs. “commercial license.”
When variants increase revenue
Variants perform well when the upgrade path is clear and the value gap is obvious. A few patterns that work:
License tiers. Selling design assets, templates, or stock content? Offer a personal-use license at $19 and a commercial license at $79. The buyer self-selects based on need, and you capture budget from both hobbyists and agencies without splitting your audience across multiple product pages.
Format bundles. If you’re selling educational content, offer the written guide alone, then add video walkthroughs or editable templates at higher tiers. The base product proves value; the upgrades save time. A $29 PDF guide might convert at 4%, while adding a $79 “PDF + videos” variant brings total revenue up 30% even if only 15% of buyers choose it.
Quantity-based pricing. This works for freelancers selling assets in packs. Ten social media templates for $15, fifty templates for $49. The per-unit savings are obvious, and buyers with larger needs convert themselves into higher-value customers.
The key commonality: the base variant is a complete, valuable product. The upgrades are enhancements, not necessities. If the cheapest option feels incomplete, you’ve built a paywall, not a product ladder.
When variants create friction instead
Too many options kill conversions. If a buyer lands on your product page and sees seven variants with unclear differences, they’ll leave to “think about it”—which means they won’t come back.
Avoid variants when:
The differences are cosmetic or arbitrary. Offering the same ebook in three different PDF layouts doesn’t add value; it adds confusion. Consolidate.
You’re trying to price-discriminate without clear tiers. Listing a product at $9, $12, $15, and $19 with vague labels like “supporter pricing” doesn’t work. Buyers assume the $9 version is incomplete or lower quality. If you want to let people pay more, use Gumroad’s “pay what you want” feature with a suggested price instead.
Your audience doesn’t understand the distinction. Selling “standard resolution” vs. “high resolution” images? Great if you’re targeting designers. Confusing if your buyers are small-business owners who don’t know what DPI means. Meet your audience where they are.
One variant mistake I see often: “basic,” “pro,” and “ultimate” tiers where the feature list for each is buried in fine print. If someone has to read three paragraphs to understand what they’re buying, simplify the structure or split into separate products.
The non-obvious tip: test your variants with SKU tracking
Gumroad doesn’t surface variant-level analytics in the main dashboard. You see total sales and revenue, but not a breakdown of which variant is actually driving volume.
Workaround: treat each variant as its own SKU in your spreadsheet or analytics tool. Export your sales CSV monthly, filter by variant name, and track conversion rate and revenue independently. You’ll often find that one variant accounts for 70% of revenue while another sits unused. That’s actionable data—either kill the underperformer or reframe it.
If you’re running paid traffic to a Gumroad product, append UTM parameters to your links and cross-reference them with variant sales in your export. You’ll see which traffic sources prefer which tiers, and you can adjust your ad creative accordingly. A Facebook ad highlighting affordability might drive base-tier sales, while a Twitter thread showcasing advanced features could skew toward your top variant.
Gumroad’s variant pricing works best when it reduces decision fatigue rather than creating it. Two or three well-differentiated options, clear value at every level, and a single product page that doesn’t require a comparison chart to navigate. Get that right, and you’ll see higher average order values without fragmenting your catalog.
Using Gumroad for your digital products, courses, or templates? Reply with your toughest pricing question—I’ll cover it in a future issue.
Ahrefs displays a “Traffic Value” number next to every domain and page it crawls. It’s supposed to represent the dollar value of your organic search traffic—what you’d pay in Google Ads to get the same visits.
It’s a seductive metric. A single number that turns traffic into money. But if you’re using it to prioritize content, justify your SEO work, or benchmark against competitors, you’re probably making decisions on bad data.
Here’s how the metric is built, where it works, and where it falls apart.
How Ahrefs calculates traffic value
Ahrefs estimates how much traffic each page receives from organic search, then multiplies that traffic by the estimated cost-per-click (CPC) for each keyword the page ranks for. The sum is your traffic value.
The formula is straightforward:
Identify the keywords a page ranks for
Estimate monthly search traffic for each keyword
Pull the CPC for each keyword from Google Ads data
Multiply traffic by CPC for each keyword, then sum it up
If your blog post ranks for “best project management software” and gets 500 visits a month, and the CPC for that keyword is $18, Ahrefs assigns that page a traffic value of $9,000 per month.
On the surface, it makes sense. You’re getting traffic you’d otherwise pay for. But the math only holds if three assumptions are true—and they rarely are.
Where the metric breaks down
First, CPC data reflects advertiser intent, not organic visitor intent. Someone searching for “Asana pricing” and clicking an ad is much closer to a purchase decision than someone clicking an organic result. Organic traffic from the same keyword converts at a lower rate, often dramatically so. Ahrefs doesn’t adjust for this.
If you’re ranking for high-CPC keywords in the B2B SaaS space—think “enterprise CRM” or “compliance software”—your traffic value will look enormous. But if those visitors are researchers, students, or early-stage browsers, the actual revenue impact is a fraction of what the metric suggests.
Second, the metric assumes you’d actually run ads for those keywords. Many high-traffic, high-CPC terms make no sense to advertise on. Informational queries, branded searches for competitors, and bottom-of-funnel terms you’d never bid on all inflate your traffic value without reflecting real alternative cost.
If your site ranks for “what is SEO,” Ahrefs might assign that traffic a high value because someone, somewhere, bids on it. But you’d never pay for that click. It’s not replacing ad spend; it’s just free traffic with a made-up price tag.
Third, CPC varies wildly by geography, device, and time. Ahrefs uses averaged CPC data, often U.S.-focused. If your traffic is global, mobile-heavy, or concentrated in lower-CPC regions, the metric overstates value. A $12 CPC keyword in the U.S. might be $2 in India, but Ahrefs doesn’t break that out in the top-line number.
When traffic value is actually useful
Despite its flaws, the metric isn’t useless. It works well in a few specific contexts.
Competitor research: If you’re comparing your site to a direct competitor in the same niche, traffic value gives you a rough sense of whose organic footprint is larger. The absolute number is still inflated, but the relative difference is directionally useful.
Content prioritization: When you’re deciding which existing pages to update or expand, traffic value can highlight pages that rank for commercially valuable keywords but aren’t fully optimized. Just don’t treat the dollar figure as literal revenue.
Executive reporting: If you need to communicate SEO impact to a non-SEO audience, traffic value translates organic performance into a language finance teams understand. Just be transparent about what it represents—avoided cost, not actual revenue.
What to use instead
If you’re trying to measure the business impact of organic traffic, skip traffic value and go straight to the metrics that matter.
Track conversions by landing page in Google Analytics 4 or your CRM. Filter for organic traffic, then see which pages drive signups, purchases, or qualified leads. That’s the actual value, not a CPC proxy.
Use Ahrefs’ traffic estimate on its own, without the dollar value. Pair it with your own conversion data to calculate real revenue per page. If a page gets 1,000 visits a month and converts at 2% to a $50 product, that’s $1,000 in monthly revenue—far more useful than a synthetic traffic value of $3,400 based on CPC data from advertisers in a different market.
If you’re evaluating content opportunities, look at keyword difficulty, search intent, and your own conversion rates for similar topics. Traffic value might tell you a keyword is “worth” $5,000 a month, but if it’s impossible to rank for or attracts the wrong audience, the number is fiction.
Ahrefs’ traffic value is a shortcut. It’s helpful when you need a quick, rough signal. But the moment you start optimizing for it, or using it to justify budget or strategy, you’re optimizing for a number that doesn’t reflect how your business actually makes money.
Measure what converts. Everything else is just math.
Got a metric you’re not sure how to interpret? Reply to this email—we’ll cover it in a future issue.
Zapier gives you two ways to handle conditional logic: filters and paths. They sound similar—both let you control what happens based on specific conditions—but they work differently, cost differently, and solve different problems.
If you’ve ever built a Zap that runs but does nothing, or one that burns through tasks faster than expected, you’ve probably picked the wrong tool for the job.
What filters do (and when they’re the right choice)
A filter is a checkpoint. It evaluates a condition and either lets the Zap continue or stops it immediately. If the condition isn’t met, the Zap ends—no further steps run, and Zapier counts it as a task used.
Filters work best when you want to exclude certain triggers from running the rest of your workflow. For example:
Only send a Slack notification if a form submission includes “urgent” in the subject line
Only add a contact to your CRM if their email domain isn’t gmail.com or yahoo.com
Only log a new row in Google Sheets if the order total is above $100
The key trait: you’re saying “if this isn’t true, do nothing.” You’re not offering an alternative action—you’re just stopping early.
One non-obvious benefit: filters are psychologically clean. When you review a Zap history and see tasks that were filtered out, you know exactly why they didn’t proceed. There’s no ambiguity, no hidden branch you forgot about.
What paths do (and when you need them instead)
Paths let your Zap fork into multiple routes based on conditions. Each path can have its own set of actions, and Zapier will execute only the path whose conditions are met. If none match, the Zap can either stop or fall through to a default path.
Paths are the right tool when you want to route a trigger to different outcomes. For example:
If a new subscriber chooses “weekly digest,” add them to MailerLite list A; if they choose “daily brief,” add them to list B
If a support ticket is tagged “billing,” create a Stripe invoice; if it’s tagged “technical,” post to a dev Slack channel
If a Typeform response selects “enterprise,” send to your CRM and notify sales; if it selects “self-serve,” send a welcome email via Postmark
The structure is “do X if A, do Y if B”—not “do X or do nothing.”
Paths count as one step in your Zap, but each action inside a path counts separately toward your task limit. If you have three paths and only one executes, you’re only billed for the actions in that path—not all three.
The mistake that burns tasks: using paths when a filter would do
Here’s the pattern I see most often: someone builds a Zap with two paths. Path A has five actions. Path B is empty, labeled “Do Nothing.”
That’s a filter dressed up as a path. And it’s wasteful.
Every time the Zap runs, Zapier evaluates the path logic—even if the result is to do nothing. You’re adding complexity and making your Zap history harder to read. Worse, if you later add actions to Path B “just in case,” you risk doubling your task usage without realizing it.
The fix: if one outcome is “do nothing,” use a filter instead. Reserve paths for workflows where every branch does something.
How they affect your task count (and your bill)
Both filters and paths count as tasks, but in different ways.
A filter counts as a task every time the Zap runs, even if the filter stops it. If 100 triggers come in and 90 are filtered out, you’ve used 100 tasks—because Zapier had to evaluate all of them.
A path counts as one task for the path step itself, plus one task for each action that runs inside the chosen path. If you have a three-path Zap and only one path executes two actions, you’ve used three tasks total (path evaluation + two actions).
This means paths can be more efficient if you’re routing high-volume triggers to different outcomes. But if you’re just trying to exclude certain triggers, a filter up front will keep your history cleaner—even if the task count is the same.
One rule of thumb that makes the decision easy
Ask yourself: if this condition isn’t met, should something else happen, or should nothing happen?
If the answer is “nothing,” use a filter. If the answer is “something else,” use paths.
That’s it. You don’t need to overthink routing logic, task costs, or Zap readability. That one question will steer you to the right tool almost every time.
Got a Zapier workflow that’s burning tasks faster than expected?Subscribe to One Two Three Send and get one operator-focused automation breakdown every week—no fluff, no beginner tutorials, just the details that matter when you’re running a real business.
