Using Make.com for WordPress: Where It Works and Where It Breaks
Make.com is a legitimate choice for multi-app automation, and we will say that plainly before anything else. If you need to connect Salesforce, Slack, Google Sheets, and a WordPress post in one scenario, Make.com handles that well.
The friction appears when WordPress is not just one stop on the journey but the center of it. Operation-based billing, data leaving your server, and limited access to WordPress internals create costs and constraints that most tutorials never mention.
This article covers the real setup process, the scenarios where Make.com earns its place, and the specific situations where a WordPress-native tool like Krom Automation costs less, runs faster, and gives you more control over your own data.
We are not here to push you away from Make.com if it genuinely fits your workflow. We are here to give you the information to make that call accurately.
How the Make.com and WordPress Connection Actually Works
Make.com connects to WordPress through the official Make Connector plugin, available in the WordPress.org plugin directory. You install it, generate an API key inside WordPress, and enter that key inside your Make.com scenario. The plugin exposes a subset of WordPress functionality over a custom REST endpoint.
The actions available through the connector cover the basics:
- Create or update a post
- Create a user
- Upload media
- Add a comment
- Manage tags and categories
That list is functional for simple content pipelines. It is not functional for anything that touches WordPress internals beyond post and user management. WooCommerce order data, custom post type meta, LearnDash enrollment events, MemberPress subscription changes, none of these are reachable through the connector without workarounds.
The alternative connection method, using Make’s HTTP module to hit the WordPress REST API directly with application password authentication, removes the connector plugin dependency. It also removes any pretense that the setup is beginner-friendly. You are manually constructing API calls, handling authentication headers, and parsing JSON responses for every action.
Operation-Based Billing: What It Costs in Practice
Make.com bills by operations, not by scenarios or tasks. Every module that executes in a scenario counts as one operation.
A scenario with 5 modules that runs 200 times per month consumes 1,000 operations. That arithmetic compounds quickly once you add filters, error handlers, data stores, or iterators.
| Make.com Plan | Monthly Operations | Monthly Cost | Cost per 1,000 Operations |
|---|---|---|---|
| Free | 1,000 | $0 | $0 (capped) |
| Core | 10,000 | $10.59/month | ~$1.06 |
| Pro | 10,000 | $18.82/month | ~$1.88 |
| Teams | 10,000 | $34.12/month | ~$3.41 |
A WooCommerce store with 300 orders per month, each triggering a 6-module scenario (fetch order, transform data, send Slack message, update sheet, tag customer, log result) consumes 1,800 operations. That fits the Core plan, until you add a second automation.
The cost is not ruinous, but it is unpredictable. A traffic spike or a marketing campaign that doubles your order volume doubles your operation consumption, sometimes pushing you into the next billing tier mid-month.
Operation-based billing sounds reasonable until you count every module in every branch of every scenario. The number is almost always higher than the estimate.
For context, WordPress automation pricing varies widely across platforms. Self-hosted plugins charge once per year or per lifetime, with no per-execution cost regardless of how many workflows fire.
Where Make.com Genuinely Wins
We want to be clear about the scenarios where Make.com is the right call, because recommending the wrong tool wastes everyone’s time.
Make.com earns its place when:
- Your WordPress site is one of several systems. If a form submission needs to create a post, update a CRM record, send a Slack notification, add a row to Google Sheets, and trigger an email campaign, Make.com handles all of that in a single scenario. A WordPress-native plugin can’t reach the external services without its own integrations for each one.
- Your team lives outside WordPress. Non-developers who are comfortable in Make.com’s visual builder but would never touch a WordPress plugin settings screen may find Make.com’s interface easier to maintain.
- The trigger is always external. If a Typeform submission or a Stripe payment is what starts the automation, and WordPress is just the destination, Make.com’s trigger library is much broader than anything WordPress-native.
- You need cross-account data routing. Moving data between separate business systems that happen to include WordPress is exactly what Make.com was designed for.
Where Make.com Creates Real Problems
The friction points are specific, and they matter for a significant share of WordPress sites.
WordPress Internals Are Out of Reach
Make.com can create a post. It cannot react to a LearnDash course completion, a MemberPress subscription expiry, a WooCommerce subscription renewal, or a user role change triggered by another plugin.
These events fire inside WordPress and are only accessible to code running inside WordPress. An external platform cannot listen to them without a webhook bridge, which adds latency, failure points, and complexity.
The connector plugin exposes what the WordPress REST API exposes. Plugin-specific events, custom database tables, and internal hooks are invisible to it.
Your Data Leaves Your Server
Every scenario that processes WordPress data sends that data to Make.com’s servers for transformation before returning a result. For most content, that is a minor concern.
For sites handling personal data, payment information, or anything under GDPR, it is a compliance consideration that requires deliberate handling. A self-hosted automation plugin processes everything on your own server, in your own database, with no data leaving the environment.
The Connector Plugin Has a Documented Bug History
WordPress.org reviews for the Make Connector plugin include reports of crashes on plugin activation, memory errors on high-traffic sites, and conflicts with security and caching plugins. These are not universal, but they are consistent enough to be a factor in your evaluation.
Sites running lean plugin stacks and standard hosting are usually fine. Sites running 40+ plugins with aggressive caching have more exposure.
Debugging a Failed Scenario Is Harder Than It Looks
When a Make.com scenario fails, the error is in Make.com’s interface. The WordPress log shows nothing unless the failure produced a PHP error.
Debugging requires switching between two systems, correlating timestamps, and often re-running the scenario manually to reproduce the issue. A WordPress-native plugin writes every step to an execution log inside WordPress, where you already are.
Debugging an automation failure should not require two browser tabs, a timestamp correlation exercise, and a manual re-run. It should show you the step that failed and why.
Real Automation Recipes: What Actually Works
Here are four scenarios with honest assessments of where each tool performs better.
| Scenario | Make.com | Krom Automation | Better choice |
|---|---|---|---|
| New WooCommerce order → Slack notification + Google Sheets row | Native. Connects both services in one scenario. | Needs Pro messaging and Sheets integrations. | Make.com, if you already subscribe |
| User registers → welcome email + role assignment | Possible via webhook, adds latency and failure points. | Native. User Registered trigger fires instantly inside WordPress. | Krom Automation |
| LearnDash course completed → certificate email | Not accessible without a custom webhook. | Native LearnDash trigger, no bridge required. | Krom Automation |
| Typeform submission → create post + notify editor | Native Typeform trigger. Clean connection. | Requires incoming webhook to receive Typeform data. | Make.com |
| Post published → AI-generated social captions + scheduled posts | Possible. Requires OpenAI module + social modules. | Native Post Published trigger + AI Generate Text + social Pro actions. | Krom Automation, cheaper at scale |
| MemberPress subscription expired → downgrade role + send email | Inaccessible. No native MemberPress trigger. | Native MemberPress trigger. See the MemberPress integration documentation. | Krom Automation |
Setting Up Make.com with WordPress: What the Tutorials Skip
Most tutorials end at “you’re connected.” Here is what happens after that.
Authentication: The Make Connector plugin generates an API key you paste into Make.com. The alternative is WordPress application passwords, introduced in WordPress 5.6, which let Make’s HTTP module authenticate without the connector plugin. Application passwords are more transparent and do not add a plugin to your stack, but constructing the API calls manually takes longer to set up.
Custom fields: The connector exposes standard post fields. Custom fields require using the REST API with a plugin like ACF that exposes meta via REST, then accessing them through Make’s HTTP module. This is documented but rarely mentioned in beginner guides.
Error handling: Make.com scenarios fail silently by default unless you add an error handler route. A scenario that fails 10 percent of the time and you never notice is worse than a scenario that never ran. Build error handler routes from the start, not after something breaks.
WooCommerce data: WooCommerce does not expose order triggers through the standard WordPress REST API in a format the Make Connector understands cleanly. The functional approach is configuring WooCommerce webhooks (Settings → Advanced → Webhooks) to push order data to a Make.com webhook URL. That works, but it is an outbound push from WordPress, not an inbound pull from Make.com.
Krom Automation as the WordPress-Native Alternative
Krom Automation is a visual workflow automation plugin built entirely inside WordPress. Every trigger fires directly from a WordPress event.
Every action runs on your server. No data leaves your database unless you explicitly call an external service.
The free version includes 16 triggers, 21 actions, and 20 workflow templates. That covers the majority of WordPress-internal automation without a paid plan. The full trigger and action model is documented, so you can verify exactly what fires and what runs before committing.
The Pro version adds 80+ additional triggers, 60+ additional actions, and 24 integrations including Mailchimp, FluentCRM, ActiveCampaign, Slack, Discord, Google Sheets, LearnDash, MemberPress, and more. For sites that need both WordPress-internal events and external service connections, Pro closes most of the gap with Make.com for scenarios that start inside WordPress.
Key differences that matter in practice:
- No per-execution cost. A Pro plan at $199 per year covers 5 sites with unlimited workflow executions. A busy WooCommerce store running 10,000 operations per month on Make.com pays that annually just in subscription fees, before accounting for operation overages.
- WordPress internals are native. LearnDash, MemberPress, WooCommerce Subscriptions, and Easy Digital Downloads are reachable as triggers without webhooks or bridges. See the LearnDash integration and WooCommerce Subscriptions integration for specifics.
- Execution logs live in WordPress. Every step of every workflow run is logged in your own database. When something fails, you see exactly which step failed and what the data looked like at that point.
- AI actions are included free. GPT-4o, Gemini 2.5, and Groq Llama models are available as actions without a separate subscription. You bring your own API key and pay your provider at standard rates. wpRigel does not mark up tokens.
Self-hosted automation means your execution history, your API credentials, and your workflow logic stay in your own database. That is not a minor convenience. It is a compliance and ownership difference.
For teams evaluating costs honestly, the full pricing comparison across WordPress automation tools is worth reading before committing to an annual platform subscription.
The Connector Plugin: Known Issues Worth Knowing
The Make Connector plugin carries a set of documented issues that do not appear in the official marketing materials. These are worth knowing before you build a production workflow on top of it.
- Memory errors on activation: Reported on shared hosting plans with limited PHP memory. Raising the memory limit to 256MB resolves most cases, but not all.
- Conflicts with security plugins: Wordfence and similar plugins occasionally block the connector’s API endpoint. Whitelisting the IP range or disabling certain firewall rules is the documented fix.
- Plugin conflicts with caching layers: Full-page caching plugins that intercept REST requests can break the authentication flow. Object caching is usually fine; full-page caching requires exceptions for the Make endpoint.
- No error visibility inside WordPress: Connector failures do not write to the WordPress error log. Debugging requires Make.com’s scenario history.
None of these are dealbreakers on a well-configured server with a lean plugin stack. On a shared host running 35 plugins, they are more likely to surface.
When to Use Each Tool
The decision is not Make.com versus WordPress plugins in the abstract. It is about where your automation starts and ends.
Use Make.com when:
- The trigger is an external service (Typeform, Stripe, Airtable, Pipedrive) and WordPress is one destination among several
- Your team already manages Make.com scenarios for other business processes and WordPress is being added to an existing workflow
- You need to route data between multiple external systems and WordPress is a minor stop
Use Krom Automation when:
- The trigger is a WordPress event: a registration, an order, a course completion, a subscription change, a form submission
- You want execution logs, analytics, and workflow history inside WordPress without switching tools
- Per-execution billing would make costs unpredictable at your traffic volume
- Plugin-specific events (LearnDash, MemberPress, WooCommerce Subscriptions) are part of the automation
- Data residency or compliance requirements mean workflow data should not leave your server
Use both when your site genuinely sits at the intersection of internal WordPress events and complex external system routing. A user completes a course in LearnDash, Krom Automation fires the internal completion trigger and updates their WordPress role, then sends a webhook to Make.com, which updates your CRM, assigns a deal stage, and notifies the sales team. The two tools can work sequentially without competing.
Practical Cost Comparison at Different Site Scales
| Scenario | Make.com annual cost | Krom Automation annual cost | Notes |
|---|---|---|---|
| 1 site, 5 simple workflows, low volume | $0 (free tier, if under 1,000 ops/month) | $0 (free plugin, permanent) | Make.com free tier is real but operation-capped |
| 1 site, 10 workflows, medium volume (~5,000 ops/month) | ~$127/year (Core plan) | $119/year (Basic Pro, 1 site) | Similar cost; Krom has no exec cap |
| 5 sites, agency, multiple workflows each | $127 to $226/year per account, or more | $199/year (Standard Pro, 5 sites) | Krom is one price for all 5 sites |
| High volume store, 500 orders/month, 6-module scenario | 3,000 ops/month. Core plan covers it, until volume grows. | $119/year, no exec cost regardless of volume | Make.com cost scales with volume; Krom does not |
Our Verdict
Make.com is a strong platform for what it was designed to do: routing data between external services in visual, multi-step scenarios. If your WordPress site is a destination inside a larger multi-app workflow, it is a reasonable choice and we would not talk you out of it.
If WordPress is the center of your automation, not a stop along the way, building on Make.com means accepting external data processing, operation billing that scales with volume, limited access to WordPress-internal events, and debugging that requires two separate interfaces. Those are real costs, not hypothetical ones.
For WordPress-first automation, Krom Automation fits the job better. The free version covers the most common internal event scenarios at no cost, permanently.
The Pro version adds the external integrations that close the gap with Make.com for workflows that start inside WordPress. You can download the free plugin from the WordPress.org plugin directory and build your first workflow without a credit card.
If you are currently paying for Make.com primarily for WordPress tasks, that is the clearest case for switching. The comparison page walks through the differences in detail: see how Krom Automation compares.
Review Krom Automation pricing and plans to find the right fit for your site count and workflow needs.
Frequently Asked Questions
Can Make.com trigger automations from WooCommerce order events?
Not natively through the Make Connector plugin. The functional approach is configuring WooCommerce’s built-in webhook system to push order data to a Make.com webhook URL when an order event fires. This works but requires setup on both the WordPress and Make.com sides, and adds a failure point if the outbound webhook times out.
Is it possible to use Make.com with WordPress without installing the connector plugin?
Yes. Make’s HTTP module can call the WordPress REST API directly using application password authentication.
You construct the API request manually inside Make.com, including the endpoint, headers, and body. It removes the connector plugin dependency but requires more technical setup for each action.
Does Krom Automation replace Make.com entirely for WordPress sites?
For workflows where the trigger and most actions are WordPress-internal, yes. For workflows where the trigger is an external service (a form tool, a payment platform, or a CRM that is not WordPress-native), Make.com’s broader trigger library still has an advantage. The two tools can also work together, with Krom Automation handling internal events and passing data outward via its HTTP Request action or incoming webhook.
Why does the Make Connector plugin sometimes crash WordPress?
Reported crashes are usually linked to insufficient PHP memory on shared hosting, conflicts with security plugins that block the connector’s REST endpoint, or interference from full-page caching layers. Raising PHP memory to 256MB, whitelisting the connector’s endpoint in your firewall, and excluding the REST API path from full-page caching resolves most cases.
How does Make.com handle WordPress authentication?
The Make Connector plugin generates an API key you enter in Make.com’s connection settings. The alternative is WordPress application passwords: create one in Users → Profile, then use it as the password in Make’s HTTP module with basic authentication. Application passwords do not require the connector plugin and give you granular control since each password can be revoked independently.