Make.com is great at moving data between apps that already have connectors. It gets awkward the moment you need something off the open web: a competitor's price, the text of an article, a fresh set of search results. There's no "scrape this page" module, and building a custom app for it feels like overkill.
You don't need one. Make ships with a generic HTTP module, and that module plus a single API call gives you scraping and search inside any scenario. Here's how to wire it up.
Why the HTTP Module Is the Whole Trick
Make's real superpower isn't its hundred pre-built connectors. It's the HTTP > Make a request module, which can call any REST API on the internet and hand the JSON response to every module downstream.
That means anything exposed as an API becomes a Make module by proxy. Web scraping is hard to package as a visual connector because every site is different, but if a scraping API takes a URL and returns clean text, calling it is just an HTTP request. The site-specific mess (rendering JavaScript, dodging blocks, retrying) lives behind the API, not in your scenario.
So the plan is simple: one HTTP module that calls a fetch-and-search API, then normal Make modules to route the result wherever you want.
Setting Up the HTTP Module
I'll use link.sc because it returns Markdown instead of raw HTML, which is far easier to map into later modules. Any API with a similar shape works the same way.
First, grab an API key. Create a free account, open the dashboard, and copy your key. The free tier is 500 requests a month, enough to build and test a scenario without paying anything.
In your scenario, add a module and search for HTTP. Pick Make a request. Configure it like this:
| Field | Value |
|---|---|
| URL | https://api.link.sc/v1/fetch |
| Method | POST |
| Headers | x-api-key = your key, Content-Type = application/json |
| Body type | Raw |
| Content type | JSON (application/json) |
| Request content | the JSON below |
{
"url": "https://example.com/products",
"render_js": true,
"format": "markdown"
}
Turn on Parse response at the bottom of the module. This is the step people skip, and it matters: with it on, Make reads the JSON automatically and exposes fields like content as mappable values in every following module. With it off, you get one giant string and have to parse it by hand.
Run the scenario once. You should see the page come back as clean Markdown in the module's output bundle.
Making the URL Dynamic
A hardcoded URL is fine for a test, but the point of automation is reacting to inputs. In Make, anything can feed that URL field.
Say a new row lands in a Google Sheet with a URL to check. Put the Sheets trigger first, then map the sheet's URL cell into the HTTP module's request body. Make's data mapping means you drag the field in; there's no code. The scenario now scrapes whatever URL shows up in the sheet.
Common trigger patterns worth stealing:
- Watch a sheet or Airtable base, scrape each new URL, write the result back to a "content" column.
- Catch a webhook from a form, scrape the submitted link, and enrich the record before it hits your CRM.
- Run on a schedule every morning to pull a page and compare it to yesterday's version.
Adding Live Web Search
Scraping assumes you already know the URL. Often you don't. You know a question, and you need whatever the web says right now.
Same module, different endpoint. Point the HTTP request at the search endpoint and send a query:
{
"q": "best electric SUV 2026 range comparison",
"limit": 5
}
You get back a list of results with titles, URLs, and snippets, already structured. From there the natural next step is a Make Iterator, which splits an array into separate bundles so every downstream module runs once per result. Search to find URLs, iterate, then fetch the full text of each one: that's a two-module research pipeline with zero code.
This is also the piece that makes Make scenarios genuinely useful for AI work. If you're feeding an OpenAI or Anthropic module later in the scenario, live search results keep it grounded in current facts instead of stale training data.
Handling Errors Like You Mean It
Scraping fails sometimes. A page 404s, a site is slow, a request times out. In Make, an unhandled error stops the whole scenario, and a scheduled scenario that dies quietly is worse than one that never ran.
Right-click the HTTP module and add an error handler. The two I reach for most:
- Break with automatic retries, for transient timeouts. Make will re-run the failed module a few times before giving up.
- Resume, to substitute a fallback value and keep going, so one dead URL in a batch of fifty doesn't kill the other forty-nine.
Also check the HTTP module's status code in a router if you want different paths for success versus failure. A 429 means you're rate limited and should slow the scenario's schedule; a 200 means you're good.
When to Use This vs. a Dedicated Scraper
Make is the right home for this when scraping is one step in a larger flow that touches other apps. It's the wrong home when scraping is the job at industrial scale.
| Situation | Use |
|---|---|
| Scrape a URL as part of a multi-app workflow | Make HTTP module + API |
| Enrich records as they arrive from a form or sheet | Make HTTP module + API |
| Search the web mid-scenario to ground an AI step | Make HTTP module + search API |
| Crawl 100,000 pages with complex link-following | A dedicated crawler in code |
| Visually point-and-click one page into a spreadsheet | A browser extension or visual scraper |
The dividing line is the same one that shows up whenever you compare an API to a full scraping stack: if the logic stays simple and the value is in connecting systems, an HTTP call inside Make beats building or hosting anything.
The Pattern Behind All of This
Once the HTTP module clicks, you stop thinking of Make as limited to its connector list. Any capability that exists as an API becomes a module you can drop into a scenario, and the messy parts (JavaScript rendering, block avoidance, retries) stay hidden behind the request.
Web scraping and search were never really missing from Make. They were just waiting for one HTTP module and an endpoint to point it at.
Want to try it in your own scenario? Create a free link.sc account, grab your API key, and paste it into a Make HTTP module in about five minutes.