One Two Three Send

Author: onetwothreeadmin

  • WordPress CDN services: when they slow your site instead of speeding it up

    WordPress CDN services: when they slow your site instead of speeding it up

    Content delivery networks sit near the top of every WordPress performance checklist. The pitch is simple: distribute static assets across edge servers, cut latency, serve files faster. For many solo operators, though, a CDN introduces more overhead than it solves—especially when you’re running a text-first site with minimal traffic.

    The problem isn’t CDNs themselves. It’s the gap between what they’re built for and how most small operators deploy them.

    When CDN cache misses cost more than direct origin requests

    A CDN works by caching copies of your assets at edge locations close to visitors. When someone requests a file, the CDN checks its cache. If the file exists (a cache hit), the CDN serves it directly. If it doesn’t (a cache miss), the CDN pulls the file from your origin server, caches it, then serves it to the visitor.

    That origin pull adds latency. For the first visitor after a cache expires, the request travels to the CDN, then to your origin, then back to the CDN, then to the visitor. That’s slower than a direct origin request—sometimes by 200–400 milliseconds.

    If your site gets 500 visitors a day and your CDN cache expires every four hours, a meaningful percentage of requests trigger origin pulls. The benefit of edge caching evaporates when cache-hit ratios stay below 70%. Sites with low traffic or frequently changing content spend more time in cache-miss penalty than they gain from edge delivery.

    Check your CDN dashboard’s cache-hit ratio. If it’s under 75%, you’re paying for infrastructure that slows more requests than it accelerates.

    HTML caching at the edge breaks dynamic WordPress features

    Most CDN providers let you cache HTML, not just static assets like images and CSS. The promise: serve entire pages from the edge without touching your origin server at all.

    The catch: WordPress is dynamic. Comment counts update. Logged-in users see personalized navigation. Cart contents change. Caching full HTML breaks all of that unless you configure cache exceptions for every dynamic element.

    Cloudflare’s default WordPress rules exclude logged-in users and query strings, but many operators enable aggressive HTML caching to chase Lighthouse scores. The result: broken checkout flows, stale post counts, and support requests from confused readers.

    If you cache HTML, you need rules that exclude:

    • Any page with cookies (wp-admin, cart, user sessions)
    • URLs with query strings (?utm_source, ?add-to-cart)
    • POST requests (forms, comments)
    • Paths where content updates frequently (/feed, /comments)

    Most small operators don’t have the traffic volume to justify the complexity. Caching assets only—images, CSS, JavaScript—delivers 80% of the performance gain with none of the breakage.

    CDN costs scale faster than traffic for small sites

    Free CDN tiers sound appealing, but bandwidth limits hit sooner than expected. Cloudflare’s free plan is genuinely unlimited for most use cases, but competitors like BunnyCDN, StackPath, and KeyCDN charge per gigabyte after you cross 100–500 GB per month.

    A single viral post with embedded images can push a small site past free-tier limits. BunnyCDN charges $0.01–0.04 per GB depending on region. If a post with 2 MB of images gets 50,000 pageviews in a weekend, that’s 100 GB of bandwidth—$1 to $4 in CDN costs. Not catastrophic, but surprising if you budgeted for free infrastructure.

    For most solo operators running text-heavy WordPress sites with under 10,000 monthly visitors, the marginal speed gain from a CDN doesn’t justify the configuration overhead or the risk of surprise bandwidth bills. A well-tuned origin server with image compression and browser caching delivers load times under two seconds—fast enough for retention and SEO.

    When a CDN actually helps

    CDNs make sense when:

    You serve large files. Video embeds, downloadable PDFs, high-resolution images, or course assets benefit from edge delivery. A 50 MB video file served from a Singapore edge node loads faster for an Australian visitor than pulling from a US origin server.

    Your traffic is geographically distributed. If your analytics show 30% of visitors from Europe, 30% from Asia, and 40% from North America, a CDN cuts cross-continent latency. If 90% of your traffic comes from one region, a well-located origin server is simpler.

    You exceed 50,000 monthly pageviews. At that scale, cache-hit ratios stabilize above 80%, and the performance gain outweighs configuration complexity.

    Before you add a CDN, run a baseline test. Use WebPageTest or GTmetrix to measure time to first byte (TTFB) and fully loaded time from multiple locations. Then enable the CDN, configure asset-only caching, and re-test. If TTFB improves by less than 150 milliseconds, the CDN isn’t doing much.

    Want more operator-to-operator breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and infrastructure decisions that matter for small online businesses. No fluff, just the details that save you time and money.

  • Social platform APIs throttle read requests faster than writes

    Social platform APIs throttle read requests faster than writes

    Most solo operators automate social posting without realizing that fetching data from social platforms burns through API quotas two to five times faster than publishing content. If you’re building workflows that pull engagement metrics, follower lists, or historical posts, you’ll hit rate limits long before your posting automation breaks.

    This asymmetry isn’t accidental. Platforms want you to publish—it’s free content for them. But reading data at scale lets you build competing analytics products, scrape competitor insights, or export your audience. So they throttle reads aggressively.

    How the limits actually break down

    Twitter’s free API tier gives you 10,000 read requests per month but allows 50,000 tweets. LinkedIn’s API (available only to approved partners) caps profile lookups at 100 per day, while post publishing has no hard daily cap for most use cases. Instagram’s Graph API allows 200 read calls per hour but handles significantly more media uploads in the same window.

    The result: you can schedule a month of posts without trouble, but a single workflow that checks your last 500 tweets for engagement stats will exhaust your quota in an afternoon.

    Publer and similar social schedulers stay within limits by caching aggressively and batching requests. If you’re building custom automation with Make or Zapier, you don’t get that layer of protection by default.

    Where automation workflows break first

    The most common failure point is analytics dashboards. A Zap that pulls yesterday’s top posts from three platforms, calculates engagement rates, and logs them to a Google Sheet will chew through 90–150 API calls per run. Do that daily, and you’re at 2,700–4,500 calls per month—just from one simple report.

    Another trap: workflows that check if a post exists before publishing a duplicate. Every existence check is a read. If you’re cross-posting the same content to Twitter, LinkedIn, and Facebook, and each platform requires a lookup to confirm the post isn’t already live, you’ve tripled your read quota burn for no publishing benefit.

    Follower-sync workflows hit limits fastest. Pulling your full follower list from LinkedIn every week to update a CRM costs 100+ calls per run if you have a few thousand connections. Do it weekly, and you’re over budget in a month.

    How to route around the limits

    Cache everything you can locally. If you need engagement data for analysis, pull it once per week and store it in Airtable, Notion, or a Google Sheet. Run reports against your own data, not the live API.

    Batch your reads. Instead of checking post performance every time you publish, schedule one daily or weekly job that fetches all recent posts in a single pass. You’ll use 7–30 calls per month instead of 200+.

    Use webhooks when platforms offer them. Facebook and Instagram can push post insights to your server when events happen, eliminating the need for polling. Twitter’s webhook support is limited, but if you’re on a paid tier, it’s worth the setup cost.

    For follower syncs, only pull deltas. Most APIs let you request changes since a timestamp. If you’re tracking new followers, ask for additions since your last check instead of re-fetching the entire list.

    When to pay for higher limits

    Twitter’s Basic tier costs $100/month and raises read limits to 10,000 per month at the app level—but it’s still far below what you’d need for daily analytics across multiple accounts. The real break-even comes if you’re running client work or managing five-plus brands. At that scale, a single shared automation hitting limits blocks everyone.

    LinkedIn doesn’t sell API access directly to solo operators. You’ll need to partner with an approved vendor or use a tool like Shield Analytics, which costs $20–50/month and includes pre-built rate-limit management.

    For Instagram, the Graph API is free but requires a Facebook Business account and app review. If you’re just scheduling posts, stick with a tool that’s already approved. If you’re building custom dashboards, expect to spend a week on the approval process and another week handling edge cases when the API changes.

    Most operators don’t need higher limits—they need smarter workflows. If you’re burning through read quotas, audit your Zaps or Make scenarios for redundant lookups, and switch to a weekly batch job. You’ll stay under free-tier caps and spend your time on content, not API accounting.

    One Two Three Send covers automation, APIs, and workflow design for solo operators every week. Subscribe here to get the next deep-dive in your inbox.

    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.

  • AI image generators bill per resolution tier—here’s the cost math

    AI image generators bill per resolution tier—here’s the cost math

    If you’re using AI image generators to create featured images, social assets, or course thumbnails, you’ve probably noticed the pricing isn’t flat. Most platforms charge based on resolution tiers—and the gap between standard and high-resolution output can be 3× to 5× per image.

    For solo operators generating dozens of visuals each week, that difference adds up fast. The trick is understanding what you’re actually paying for, and when the premium tier is wasted spend.

    How resolution-based pricing works

    Most AI image platforms structure pricing around three dimensions: the number of images generated, the resolution of the output, and whether you’re using a fast or slow generation queue.

    Midjourney, for example, offers standard and high-resolution upscaling. A standard 1024×1024 image costs one credit. Upscaling to 2048×2048 or higher costs additional credits—often two to four times the base rate. DALL·E 3 via OpenAI’s API charges $0.040 per standard 1024×1024 image, $0.080 for 1024×1792, and $0.120 for 1792×1024. Stability AI’s models follow a similar pattern: higher pixel counts mean higher API costs.

    The resolution tier you pick determines not just image quality, but also processing time, server load, and—in some cases—access to advanced features like inpainting or style transfer at full fidelity.

    When high resolution matters

    If you’re creating print assets, large hero images for landing pages, or anything that will be displayed at native resolution on high-DPI screens, the premium tier makes sense. A 2048×2048 image gives you flexibility to crop, zoom, or repurpose without visible artifacting.

    But most online-business use cases don’t need that headroom. Featured images for blog posts get compressed to under 200 KB for page speed. Social media platforms downsample uploads aggressively—Instagram compresses anything over 1080px wide, and Twitter re-encodes at 1200×675 for timeline cards. If your workflow ends with a resize and export at 80% JPEG quality, you’re paying for pixels you immediately discard.

    One operator I spoke with was generating 1792×1024 images in DALL·E for newsletter headers, then running them through TinyPNG and resizing to 600px wide. She was spending $0.080 per image when $0.040 would have produced an identical final asset. Over a month of daily emails, that’s an extra $1.20—small in isolation, but it scales with volume and points to a larger pattern of over-provisioning.

    The resolution-to-use-case map

    Here’s a practical breakdown by output type:

    • Social media thumbnails, Twitter cards, Facebook link previews: 1024×1024 or 1024×576 is enough. Platforms compress aggressively.
    • Blog featured images: 1200×630 covers Open Graph and gives you crop flexibility. Standard-tier generation works fine.
    • Email headers: 600–800px wide at 72 DPI. Standard resolution, then resize in post.
    • Course or product thumbnails: If displayed under 500px, standard resolution suffices. If users click to expand or you offer print options, go higher.
    • Paid ads (Meta, Google Display): Check the platform’s recommended specs. Most want 1200×628 or 1080×1080. Standard tier handles it.
    • Print, merchandise, or high-res downloads: This is where premium tiers pay off. Aim for 2048px minimum on the short edge.

    If you’re unsure, generate one image at standard resolution, run it through your normal export pipeline, and inspect the final file. If it looks sharp at the intended display size, you don’t need to pay more.

    Batch generation and cost control

    Most platforms let you queue multiple images in a single prompt or API call. If you’re producing a set of related visuals—say, five variations of a hero image for A/B testing—generate them all at standard resolution first, pick the winner, then upscale only that one if needed.

    Some tools, like Stability AI’s API, let you set resolution as a parameter. If you’re building a workflow in Make or Zapier that triggers image generation on new blog posts, hardcode the resolution to 1024×1024 unless the content type explicitly requires more. That prevents accidental overspend when someone forgets to set the dropdown.

    For high-volume operators, consider running a monthly audit: export your image generation logs, compare resolution tier usage to final published asset specs, and flag any mismatches. If you’re consistently generating 1792px images and publishing 800px, adjust your defaults.

    When to ignore the math

    If your brand aesthetic depends on ultra-sharp, large-format visuals—or if you regularly repurpose the same asset across print, web, and social—paying for high resolution up front can save time. Generating once at 2048px and resizing down for different channels is faster than re-generating multiple times.

    But for most solo operators, the reverse is true: generate at the resolution you’ll actually use, and upgrade selectively when the output demands it. The savings are small per image, but they compound across hundreds of assets and dozens of projects.

    What’s your default resolution when you generate images? Hit reply and let me know—I’m curious whether most operators overprovision or dial it in tight.

  • Analytics UTM parameters break when platforms strip them mid-click

    Analytics UTM parameters break when platforms strip them mid-click

    You set up UTM parameters on every campaign link. You check your analytics dashboard. Half your traffic shows up as direct or referral with no campaign data attached. The parameters vanished somewhere between the user’s click and your server log.

    This isn’t a tagging mistake or a broken implementation. Social platforms, email clients, mobile apps, and third-party proxies strip, modify, or cache UTM parameters before they ever reach your site. The problem is structural, and it costs solo operators accurate attribution data every single day.

    Where UTM parameters disappear

    Instagram and TikTok in-app browsers cache the destination URL on first load, then serve that cached version on subsequent taps. If a user sees your post, taps the link, backs out, then taps again five minutes later, the second visit hits your site without UTM parameters because the app pulled the page from cache instead of following the full URL.

    LinkedIn’s link wrapper rewrites URLs when you post. A link with ?utm_source=linkedin&utm_medium=social&utm_campaign=launch gets routed through linkedin.com/safety/go, and sometimes the parameters don’t survive the redirect chain. The same happens on Facebook when the platform flags your domain for review or routes traffic through its link-shim service.

    Email clients strip query parameters they consider tracking identifiers. Apple Mail Privacy Protection prefetches links in the background, and iOS Mail strips parameters on some mailto and http links when the user has tracking protection enabled. Outlook’s Safe Links feature rewrites URLs and occasionally drops trailing parameters during rewrite.

    Link shorteners add another failure point. Bitly, TinyURL, and custom short-domain services sometimes cache the redirect destination. If you update the long URL with new UTM parameters after the short link is created, users who clicked the old short link may land on a cached version with stale or missing parameters.

    What actually survives

    UTM parameters work reliably on direct web traffic and on platforms that don’t proxy or rewrite links. Twitter/X still passes them through cleanly most of the time. Reddit does, too, unless the subreddit uses AutoModerator rules that strip query strings. Email platforms like MailerLite and Postmark preserve UTM parameters in plain-text and HTML emails as long as the link isn’t flagged by the receiving client’s anti-tracking filter.

    Search ads and display ads pass parameters without issue because the ad platform has no incentive to strip your tracking data—they want you to measure performance so you keep spending. Google Ads, Microsoft Ads, and Meta Ads all respect UTM conventions.

    Direct links posted in Slack, Discord, SMS, and WhatsApp usually work, though WhatsApp’s link preview service occasionally caches the destination and serves a parameter-free version on repeat taps.

    Workarounds that don’t scale

    Some operators try to append a cache-buster parameter like &cb=1234567890 to force platforms to treat each link as unique. This helps with caching issues but increases the risk that aggressive filters flag the URL as a tracking link and strip the entire query string. You trade one failure mode for another.

    Others embed campaign identifiers in the URL path instead of query parameters: example.com/launch-linkedin instead of example.com?utm_campaign=launch. This survives stripping but requires server-side rewrite rules and breaks when you run multiple campaigns to the same landing page. You end up creating dozens of duplicate URLs or writing complex routing logic.

    A third approach is to use first-party cookies or localStorage to persist campaign data after the first visit, then attribute conversions retroactively. This works only if the user converts on a return visit and only if your analytics tool supports cross-session attribution. Most don’t.

    What actually works

    Accept that UTM parameters will fail on 15–30% of clicks from social and email traffic. Plan your attribution model around that reality instead of trying to patch every leak.

    Use a dedicated link-management tool like Rebrandly or a self-hosted solution that logs the original UTM parameters server-side when the short link is created, then appends them to the destination URL at redirect time. This won’t fix client-side caching, but it ensures your tracking data is attached to the redirect, not just the short link.

    For high-value campaigns, create unique landing pages with campaign identifiers baked into the URL path. Reserve this for product launches, partnerships, and sponsored placements where you need accurate attribution and can afford the operational overhead.

    Track referrer headers alongside UTM parameters. When parameters are missing, your analytics tool can fall back to the HTTP referer header to identify the source platform. This won’t give you campaign-level detail, but it’s better than marking everything as direct traffic.

    Run a monthly audit of your top traffic sources in Google Analytics, Plausible, or Fathom. Filter for sessions with no UTM parameters and a known referrer domain. If you see significant traffic from l.instagram.com, lm.facebook.com, or t.co tagged as direct, you know where your parameters are breaking.

    Want to dig deeper into analytics setup and attribution models for solo operators? Reply with the tracking issue you’re trying to solve—we’ll cover it in a future issue.

  • ConvertKit custom fields bloat subscriber profiles—when to use tags instead

    ConvertKit gives you two ways to track information about subscribers: custom fields and tags. Most operators pick one by habit or intuition, then run into performance problems, automation failures, or segmentation nightmares six months later.

    The difference isn’t just semantic. Custom fields and tags work differently under the hood, cost differently at scale, and break in different ways when you push them too hard.

    What custom fields actually store

    Custom fields hold variable data—strings, numbers, dates—unique to each subscriber. Think first name, referral source, purchase count, or renewal date.

    ConvertKit stores these as key-value pairs in your subscriber record. You can reference them in emails with liquid syntax ({{ first_name }}), filter segments by their values, and update them via API or form submission.

    The gotcha: every custom field you create adds a column to every subscriber record, whether populated or not. An empty field still exists in the database. Add twenty fields and you’re carrying twenty columns per contact, even if nineteen are blank.

    This doesn’t break anything immediately. But it slows segment queries, complicates exports, and makes your data harder to audit. I’ve seen accounts with forty-plus custom fields where only six held useful information. The rest were legacy experiments or half-finished automations.

    What tags actually track

    Tags are binary flags. A subscriber either has a tag or doesn’t. You can’t store a value in a tag—just presence or absence.

    ConvertKit indexes tags separately from subscriber records. Adding a tag doesn’t expand the subscriber table. It creates a relationship record in a join table. That architecture scales better when you’re tracking dozens of attributes.

    Tags also surface better in the UI. You can see all applied tags at a glance in the subscriber list. Custom field values require opening each record or exporting a CSV. For quick visual checks—who’s in the beta cohort, who opted into coaching—tags win.

    The downside: tags can’t hold nuance. If you need to store when someone joined the beta or which tier they purchased, a tag won’t cut it. You’ll end up creating beta_joined_2026_01, beta_joined_2026_02, and so on—tag sprawl that’s worse than a single date field.

    When to use custom fields

    Reach for custom fields when you need to store or reference a specific value:

    • Personalization tokens in email copy (first name, company, city)
    • Numeric counters that increment (emails opened this month, courses completed)
    • Dates for time-based logic (trial start date, last purchase, renewal window)
    • External IDs for syncing with other tools (Stripe customer ID, WordPress user ID)

    Custom fields also make sense when you need to filter segments by ranges or partial matches. “Purchase count greater than 3” or “City contains ‘New’” requires field-based logic. Tags can’t do that.

    When to use tags

    Use tags for binary states, audience segments, and behavioral flags:

    • Lifecycle stages (subscriber, buyer, churned, reactivated)
    • Interest categories (AI tools, WordPress, monetization)
    • Engagement tiers (active, dormant, cold)
    • Cohort membership (joined Q1 2026, beta tester, workshop attendee)

    Tags scale better when you’re tracking many attributes that most subscribers won’t have. If only 8% of your list are buyers, a buyer tag is leaner than a is_buyer custom field sitting empty on 92% of records.

    Tags also play nicer with automation branching. ConvertKit’s visual automations let you split paths based on tag presence with a single click. Doing the same with custom field values requires more setup and is harder to debug when it breaks.

    The hidden cost of choosing wrong

    I’ve worked with a SaaS newsletter operator who used custom fields for everything—including audience interests. They had fields like interested_in_AI, interested_in_SEO, and interested_in_monetization, each storing “yes” or blank.

    Segmenting required filtering by six different field conditions. Automations couldn’t branch cleanly. Exports included twelve columns of “yes” and empty cells. Switching to tags cut segment load time from four seconds to under one and made the automation map readable again.

    Conversely, I’ve seen operators try to use tags for dates. They’d create trial_started_2026_06_15, then realize a week later they couldn’t query “trial started more than 7 days ago” without manually adding 365 tags. A single trial_start_date custom field solved it.

    One non-obvious tip

    You can combine both. Use a custom field to store the precise value and a tag to mark the category.

    Example: store last_purchase_date as a custom field (for time-based logic and reference), then apply a buyer tag (for quick filtering and automation branching). The field gives you precision; the tag gives you speed.

    This hybrid approach works especially well for high-cardinality data—attributes that can take many values but where you still want fast segment access. Referral source is another good candidate: store the exact UTM in a field, apply a referral_traffic tag.

    Before you create your next custom field or tag, ask: am I storing a value I need to reference, or am I marking a state I need to check? The answer tells you which to use.

    Got a ConvertKit setup question? Reply to this email—I read every one, and reader questions become future articles.

  • Zapier vs. Make vs. n8n: which automation platform to pick

    Zapier vs. Make vs. n8n: which automation platform to pick

    Workflow automation tools promise to glue your stack together—newsletter platform to CRM, form submissions to Slack, payment webhooks to spreadsheets. But the three most popular platforms—Zapier, Make, and n8n—differ sharply in pricing model, learning curve, and where they break under load.

    Here’s how to pick the right one for your online business, based on technical comfort and workflow complexity.

    Zapier: the fastest onramp, highest per-task cost

    Zapier is the incumbent. Its library covers 6,000+ apps, the UI is beginner-friendly, and most workflows take under ten minutes to build. You connect two apps, pick a trigger, map fields, and hit publish.

    Pricing starts at $19.99/month for 750 tasks. A “task” is any action—sending an email, creating a row, posting to Slack. Multi-step Zaps consume one task per step. If you’re running a weekly digest that pulls 50 rows from Airtable, formats them, and sends via Postmark, that’s 100 tasks per send (50 read actions + 50 format actions). At moderate volume, you’ll hit the 750-task ceiling fast.

    The $49/month tier gives you 2,000 tasks and multi-step Zaps. The $69 tier unlocks 5,000 tasks and premium apps like Salesforce. After that, overage is $0.01–0.03 per task depending on plan.

    Zapier is best for: solo operators who want speed over cost efficiency, workflows under 1,000 tasks/month, and teams with zero dev resources.

    Where it breaks: Complex conditional logic requires nested filters that eat tasks. Error handling is limited—if step three fails, the whole Zap dies unless you add error-catching steps (more tasks). Debugging multi-step Zaps means clicking through each execution log manually.

    Make: visual logic, cheaper at scale

    Make (formerly Integromat) uses a node-based canvas. You drag modules onto a board, draw connections, and configure routers, filters, and loops. It’s more visual than Zapier but steeper to learn.

    The key difference: Make charges by operations, not tasks, and counts more efficiently. A single HTTP request that returns 50 records and pipes them through a filter counts as two operations (fetch + filter), not 50. For bulk workflows, this cuts cost dramatically.

    Pricing starts at $9/month for 10,000 operations. The $16 tier gives you 40,000. Even the free tier includes 1,000 operations—enough to test real workflows. Make also includes built-in error handling, rollback, and scenario versioning at every tier.

    Make is best for: operators comfortable with flowcharts, workflows that process batches (RSS to social, CSV imports, webhook queues), and anyone hitting Zapier’s task ceiling.

    Where it breaks: The UI intimidates non-technical users. App connectors are less polished than Zapier’s—some require manual API setup. The execution log is powerful but dense; reading it requires understanding JSON structure.

    n8n: self-hosted, unlimited operations, steepest learning curve

    n8n is open-source. You host it yourself (DigitalOcean, AWS, or your own VPS) or pay for n8n Cloud. The workflows look similar to Make—nodes, connections, conditional branches—but you control the infrastructure and pay nothing per operation.

    Self-hosting costs $5–20/month depending on server size. n8n Cloud starts at $20/month for 2,500 executions (an execution is one full workflow run, regardless of steps). The free Cloud tier allows 50 executions/month.

    n8n’s power is in flexibility. You can write JavaScript inside nodes, call custom APIs, manipulate data inline, and trigger workflows via webhook, cron, or manual button. It’s the only platform where you can run a workflow locally, version-control it in Git, and deploy via CI/CD.

    n8n is best for: technical founders, dev-friendly teams, workflows that need custom code, and businesses running 10,000+ operations/month where per-task pricing becomes prohibitive.

    Where it breaks: You’re responsible for uptime, backups, and security. The app connector library is smaller (400+ apps vs. Zapier’s 6,000). Some integrations require OAuth app setup or API keys that aren’t documented. If you’re non-technical and your server goes down at 2am, you’re stuck.

    How to decide

    Start with your monthly operation count and technical comfort.

    If you’re running under 1,000 tasks/month and want zero friction, use Zapier. If you’re processing batches—pulling 200 RSS items daily, importing CSVs, or handling webhook queues—switch to Make before you hit Zapier’s $69 tier. If you’re technical, running 10,000+ operations, or need version control and custom logic, self-host n8n.

    One non-obvious move: use Zapier for the first 90 days to validate workflows, then migrate the high-volume ones to Make or n8n once you know they’re permanent. Rebuilding a workflow in Make takes 20–40 minutes if you understand the original logic.

    Most solo operators land on Make. It’s the sweet spot between Zapier’s ease and n8n’s control, and the $16/month tier covers 95% of real-world use cases.

    Have a workflow question? Reply to this email—we read every one and answer the best questions in future issues. Subscribe here if someone forwarded this to you.

  • Google Search Console’s URL Inspection Tool: What It Actually Tests

    Google Search Console’s URL Inspection Tool: What It Actually Tests

    Google Search Console’s URL Inspection tool sits at the top of every SEO operator’s diagnostic stack. You paste a URL, hit Enter, and get a verdict: indexed or not, crawlable or blocked, mobile-friendly or broken.

    But the tool checks more than you think—and sometimes lies about what it finds. Here’s what actually happens when you inspect a URL, what the results mean, and when to ignore them entirely.

    What the Tool Actually Checks

    When you run an inspection, Google fetches the live version of your page and compares it against the last indexed snapshot. The report breaks into two columns: URL is on Google (the indexed version) and Live Test (what Googlebot sees right now).

    The live test runs through:

    • Crawlability: Can Googlebot access the page? Checks robots.txt, meta robots tags, X-Robots-Tag headers, and server response codes.
    • Rendering: Does the page load JavaScript successfully? Google uses a recent Chromium version, but timeouts still happen.
    • Mobile usability: Viewport settings, text size, tap target spacing. Google indexes mobile-first, so this matters even if your traffic skews desktop.
    • Structured data: Parses schema.org markup and flags errors or warnings.
    • Canonical tag: Confirms whether your declared canonical matches Google’s selected canonical.

    The indexed column shows what Google already cached. If you recently changed the page, the two columns won’t match. That’s normal—but it also means you can’t trust the indexed column to reflect current reality.

    When the Tool Misleads You

    The live test doesn’t guarantee indexing. It only proves Googlebot can crawl the page. Google may still choose not to index it due to quality signals, duplicate content, or crawl-budget constraints.

    I’ve seen pages pass every live test—green across the board—yet remain excluded for months. The tool won’t tell you why. You’ll need to cross-reference the Coverage report and check for “Crawled – currently not indexed” or “Discovered – currently not indexed” flags.

    The rendering preview also lies occasionally. Google’s renderer times out after five seconds for most JavaScript execution. If your React app or WordPress theme loads critical content late, the preview may show a blank page even though real users see the full layout. Compare the screenshot against an incognito browser session to catch this.

    Structured data validation in the URL Inspection tool is stricter than the separate Rich Results Test. A page might fail in the inspector but still earn rich snippets in search. If you’re optimizing for featured snippets or product schema, validate in both tools.

    The “Request Indexing” Button and What It Actually Does

    After running a live test, you can click Request Indexing. Google adds the URL to a priority crawl queue, but it’s not instant—and it’s not a guarantee.

    The queue processes within a few hours to a few days, depending on your site’s overall crawl budget and domain authority. High-authority sites see faster indexing. New domains or sites with thin content wait longer.

    You get a limited number of indexing requests per property per day. Google doesn’t publish the exact quota, but operators report hitting limits around 10–12 requests in 24 hours. If you’re launching a batch of new pages, prioritize the ones that drive revenue or backlink to other content.

    One non-obvious tip: request indexing for your XML sitemap URL itself after adding new pages. This signals Google to re-crawl the sitemap and discover the new URLs faster than waiting for the next scheduled sitemap fetch.

    When to Use It vs. When to Wait

    Use the URL Inspection tool when:

    • You’ve fixed a crawl error or removed a noindex tag and need to confirm the change took effect.
    • You’ve published time-sensitive content—event coverage, product launches, breaking commentary—and need Google to pick it up within hours.
    • You’ve updated a high-traffic page and want to verify rendering before Google re-indexes on its own schedule.
    • You’re debugging why a page isn’t appearing in search despite being live for weeks.

    Skip it when:

    • You’re publishing evergreen content that doesn’t compete on speed. Let Google’s normal crawl cycle handle it.
    • You’ve already requested indexing for the same URL in the last 48 hours. Repeated requests don’t speed things up.
    • The page is thin, duplicate, or low-quality. Requesting indexing won’t override Google’s quality filters.

    The tool works best as a diagnostic instrument, not a publishing workflow. If you’re hitting the request-indexing button for every post, you’re either publishing too much low-value content or your site has deeper crawl-budget problems that no amount of manual requests will fix.

    One Two Three Send covers SEO tools, traffic strategy, and operator workflows every week. Subscribe here to get the next breakdown in your inbox.

  • Beehiiv’s boost network: when paid discovery costs more than it delivers

    Beehiiv’s boost network: when paid discovery costs more than it delivers

    Beehiiv‘s Boost network lets you pay to place your newsletter in front of other publishers’ audiences. You set a cost-per-subscribe bid, the network distributes your sign-up form as a recommendation block in other newsletters, and you pay only when someone converts.

    It sounds clean: growth on demand, no creative work, pay-per-result pricing. But the unit economics break down faster than most solo operators expect, and the subscriber quality often doesn’t match what you’d get from a direct swap or organic channel.

    How Boost pricing actually works

    You bid per subscriber. Beehiiv suggests a minimum around $1.00 to $2.00 depending on your niche, but competitive categories—business, finance, tech—regularly see bids north of $3.50. The platform runs an auction: your bid competes against other newsletters targeting similar audiences, and higher bids get more placement.

    If you’re spending $3.00 per subscriber and converting 100 sign-ups, that’s $300. Compare that to a single well-placed guest post, a Reddit comment thread that goes viral, or a reciprocal mention in a newsletter with 5,000 engaged readers. Those channels cost time, not cash, and the subscribers tend to stick around longer because they arrived with context.

    Boost also takes a 20% platform fee on top of your bid when you’re the one receiving the promotion revenue. So if another publisher is willing to pay $2.00 per subscriber to reach your audience, you only net $1.60. That margin matters if you’re considering Boost as a two-sided marketplace—running campaigns and monetizing your own list simultaneously.

    Subscriber quality lags behind owned channels

    Boost subscribers convert at the point of least intent. They see a recommendation block, often at the bottom of someone else’s newsletter, and click through with minimal context about what you publish. Compare that to someone who found you via search, read three articles, then subscribed—or someone who saw you interviewed on a podcast and went looking for your sign-up page.

    The data backs this up. Operators I’ve spoken with report Boost subscribers opening 10–15 percentage points lower than their list average, and unsubscribe rates spike in the first three sends. You’re not buying an audience; you’re renting attention from people who were already reading something else.

    That doesn’t make Boost useless—it makes it a cold-traffic channel. If your welcome sequence is strong and your first three emails do the work of educating and filtering, you’ll retain some of those subscribers. But if you’re comparing cost-per-acquisition across channels, Boost often ranks as the most expensive per engaged subscriber, not just per sign-up.

    When Boost makes sense (and when it doesn’t)

    Boost works if you have a monetization model that converts cold traffic quickly—like a low-ticket digital product, an affiliate funnel, or a sponsored placement you’re testing. You can afford a $3.00 CPA if your average subscriber generates $8.00 in affiliate commissions in the first 30 days. The math breaks even, and you’re buying reach you couldn’t generate organically in the same timeframe.

    It also works as a diagnostic tool. Run a small Boost campaign with $100–$200, track open rates and unsubscribe behavior, and compare the cohort to your organic subscribers. If the gap is narrow, your welcome sequence is doing its job. If Boost subscribers churn at 40% in week one, you know the acquisition channel isn’t the only problem—your onboarding needs work.

    Where Boost fails: when you’re pre-revenue, when your content needs warm context to make sense, or when you’re trying to grow a tight community rather than a broadcast list. Paying $2.50 per subscriber to add 500 unengaged emails to your list doesn’t move your business forward. It inflates a vanity metric and increases your monthly platform costs if you’re on a plan that charges per contact.

    Compare Boost to organic cross-promotion first

    Before you allocate budget to Boost, exhaust direct swaps. Reach out to five newsletter operators in adjacent niches—not competitors, but publishers whose audience would genuinely benefit from your content—and propose a mutual recommendation. No money changes hands. You write a 50-word blurb about them, they write one about you, and you both send it to your lists.

    A single swap with a newsletter that has 3,000 engaged readers can net you 30–80 subscribers at zero cost, and those subscribers already trust the curator who recommended you. That’s a conversion rate and engagement quality Boost struggles to match, even at $4.00 per sign-up.

    If organic swaps aren’t yielding results, the problem is usually positioning, not distribution. Fix your one-sentence pitch, tighten your welcome email, and make sure your archive demonstrates consistent value. Then revisit paid channels.

    One thing to try this week: If you’re on Beehiiv and considering Boost, run a $100 test campaign and tag those subscribers in a separate segment. Compare their 30-day open rate and unsubscribe rate to your organic cohort from the same period. If the gap is wider than 20 percentage points, reallocate that budget to a guest post or a direct swap instead.

    Have a question about newsletter growth tactics or want to share your own Boost numbers? Hit reply—I read every response.

    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.

  • WordPress managed hosting SSH access: what you lose and why

    WordPress managed hosting SSH access: what you lose and why

    When you move from a VPS or shared cPanel host to managed WordPress hosting, one of the first things you might notice is limited—or completely absent—SSH access. Some hosts disable it by default. Others gate it behind higher-tier plans. A few remove it altogether and route everything through proprietary dashboards or Git workflows.

    If you’ve spent years running wp-cli commands, deploying via rsync, or tailing error logs in real time, the loss stings. But managed hosts aren’t just being difficult. The trade-off is deliberate, and understanding it helps you decide whether the convenience is worth what you’re giving up.

    What actually disappears when SSH goes away

    The most immediate loss is direct command-line access to your WordPress install. That means:

    • No WP-CLI. Bulk operations—importing posts, regenerating thumbnails, flushing rewrite rules—now require plugins or support tickets.
    • No custom deploy scripts. If your workflow relies on rsync, scp, or Git hooks that push files directly to the server, you’ll need to adapt to the host’s deployment tools or SFTP.
    • No real-time log access. Tailing error.log or access.log via SSH is out. Most managed hosts surface logs through their dashboard, but with a delay—sometimes five to fifteen minutes.
    • No cron job customisation. If you’ve been scheduling tasks via crontab -e, you’re now limited to WordPress’s built-in wp-cron or the host's scheduled task interface.

    For solo operators who've built muscle memory around SSH workflows, this feels like a downgrade. And in some cases, it is.

    What you gain in exchange

    Managed WordPress hosts strip SSH access because it reduces the surface area for things to break. When they control how you interact with the server, they can:

    • Enforce object caching and page-cache rules. Hosts like Kinsta and WP Engine bake Redis or Memcached into the stack and manage purge behaviour automatically. If you could SSH in and flush caches manually, you'd bypass their optimisations—and their support team would struggle to diagnose performance issues.
    • Prevent bad plugin installs. Some hosts scan uploads and block known-bad plugins or themes before they hit the filesystem. SSH access would let you sidestep that.
    • Standardise environments. When everyone uses the same deployment method—whether it's SFTP, a Git push, or a dashboard upload—the host can guarantee file permissions, directory structure, and PHP handler consistency.

    The result: faster support, fewer "it works on my machine" tickets, and a tighter performance baseline. For operators who don't want to think about server tuning, that's a win.

    When the restriction actually hurts

    SSH restrictions cause real problems in three scenarios:

    Migration and bulk imports. If you're moving a large site—10,000+ posts, extensive custom taxonomies, or complex metadata—WP-CLI's import commands are orders of magnitude faster than browser-based plugins. Without SSH, you're stuck waiting for PHP timeouts or splitting files into tiny batches.

    Custom integrations. If your business relies on a custom sync script—pulling data from an external API and writing it directly to wp_postmeta, for example—you'll need to rewrite it as a plugin or cron job that runs inside WordPress's PHP environment. That's slower and harder to debug.

    Granular troubleshooting. When a plugin conflict or theme bug crashes your site, SSH access lets you rename directories, disable plugins via the filesystem, and check error logs in real time. Without it, you're waiting for support to do it for you—or fumbling with SFTP and hoping you don't make things worse.

    How to adapt (or avoid the problem)

    If you're on a managed host without SSH and you need command-line access, a few hosts offer middle-ground options:

    • BigScoots offers SSH on all managed WordPress plans, with WP-CLI pre-installed. You get the performance stack and support model of managed hosting without losing terminal access.
    • Cloudways and GridPane both provide full SSH and let you configure cron jobs, deploy via Git, and run custom scripts.
    • Kinsta and WP Engine don't offer SSH, but both have robust staging environments and Git-based deployment workflows. If you can shift your workflow to Git push instead of rsync, you'll regain most of the flexibility.

    If you're evaluating hosts and SSH is non-negotiable, ask explicitly during onboarding. Some sales reps will say "limited SSH" when they mean "SFTP only." Get specifics: can you run WP-CLI? Can you tail logs? Can you schedule cron jobs outside WordPress?

    The real question

    SSH access isn't inherently good or bad. It's a tool. If your workflow depends on it—bulk imports, custom scripts, real-time debugging—choose a host that supports it or be ready to rewrite your processes. If you'd rather offload server management entirely and trust the host's optimisations, the loss won't hurt.

    The mistake is assuming all managed WordPress hosting is the same. It's not. Some hosts remove SSH to simplify support. Others preserve it because their customers need it. Know which camp you're in before you sign up.

    What's your experience? Hit reply and let us know whether SSH restrictions have been a dealbreaker or a relief. We read every response.

  • Social media carousel posts: when ten slides kill engagement

    Social media carousel posts: when ten slides kill engagement

    Platform algorithms love carousel posts. Instagram, LinkedIn, and Facebook all reward multi-slide content with extended reach because users spend more time swiping through them. That’s the pitch, anyway.

    The reality for solo operators: most carousels perform worse than single-image posts because completion rates tank after slide three. You get the initial engagement bump, then watch 80% of your audience bail before seeing your call-to-action on slide ten.

    Here’s what actually works, based on engagement data from operators running content businesses on Instagram and LinkedIn.

    The completion cliff happens at slide four

    LinkedIn’s own analytics show that carousel posts with four to six slides get the highest completion rates—around 60% of people who engage will see the final slide. Push that to eight slides and completion drops to 35%. Go to ten or twelve slides and you’re looking at 15-20% completion.

    Instagram’s behavior is similar. Posts with three to five slides maintain swipe-through rates above 50%. Beyond that, users assume the content is either repetitive or padded, and they scroll past.

    This matters because most operators bury their CTA on the last slide. If only 20% of engaged users see it, your conversion rate collapses no matter how good the top-of-funnel hook is.

    Slide count vs. content density

    The advice to “add value on every slide” sounds good, but it creates a different problem: cognitive load. If each slide introduces a new concept, tool, or step, users disengage because they can’t process ten discrete ideas in 30 seconds.

    High-performing carousels follow a different structure:

    • Slide 1: Hook or thesis—one sentence, large text, high contrast.
    • Slides 2-4: Core content. Each slide elaborates one point. No new concepts after slide four.
    • Slide 5: CTA or summary. Assume this is the last slide most people see.
    • Optional slide 6: Secondary CTA or credential-builder (“I’ve done this for X clients” or “This drove Y result”).

    If you need more than six slides to make your point, you’re either covering too much ground or padding for algorithmic favor. Both backfire.

    When to use ten slides anyway

    Long carousels work in two situations: lead magnets and tutorials where users expect to save the post for later.

    If your carousel is a step-by-step guide to setting up a WordPress staging site or a checklist for launching a paid newsletter, users will save it and return when they need it. Completion rate on first view doesn’t matter—saves and shares become your primary metric.

    In this case, slide ten can hold your CTA because the user who saves the post will eventually scroll through the full sequence when they’re ready to act. You’re optimizing for intent, not impulse.

    But if your goal is immediate engagement—replies, profile visits, link clicks—keep it to five slides or fewer. The algorithm boost from a carousel format isn’t worth a 70% completion drop.

    Scheduling tools and slide limits

    Most social scheduling platforms support carousels, but slide limits vary. Publer lets you upload up to ten images per carousel for Instagram and LinkedIn. Buffer caps LinkedIn carousels at fifteen slides but warns that performance drops after six. Later supports up to ten slides across platforms but doesn’t auto-optimize for completion rates.

    None of these tools will stop you from uploading a twelve-slide carousel. They also won’t tell you that your engagement rate is about to fall off a cliff.

    If you’re batch-scheduling carousels, set a internal rule: five slides maximum unless the post is explicitly a save-and-reference resource. Track completion rate (Instagram Insights and LinkedIn analytics both surface this) and compare it against your single-image posts. If carousels aren’t outperforming by at least 20%, you’re wasting time on extra slides.

    What to do instead

    If you have ten points to make, split them into two carousels published a week apart. Each one will get better completion rates, and you’ll have two chances at algorithmic distribution instead of one post that half your audience abandons.

    Alternatively, post a three-slide carousel as a hook, then drive traffic to a blog post or newsletter archive where you can expand without fighting platform attention spans.

    Carousels are a formatting choice, not a strategy. If the content doesn’t justify multiple slides, a single strong image with a tight caption will outperform a padded carousel every time.

    What’s working for you? Reply with your average carousel completion rate—I’m tracking operator benchmarks for a future piece.

    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.

Powered by CookieAdmin