Scrape a Web Page and Summarise It with Claude

Build a no-code Make workflow that fetches a web page, cleans its content, sends it to Claude, and delivers a reliable summary.

Use Make to fetch a page, remove navigation and other clutter, send the readable text to Claude, and deliver a structured summary whenever the page changes.

Start with a public page that has a stable URL and a clear business use, such as a supplier update, competitor pricing page, policy page, or industry announcement. Avoid starting with a login-only page, a heavily interactive dashboard, or a page protected by a paywall. Those pages often return incomplete content to no-code HTTP tools.

Decide what the summary must help you do before building the automation. “Summarise this page” is too vague. A useful instruction might be, “Extract the three changes since the previous version, explain who is affected, and quote the relevant heading for each change.” The desired decision determines what Claude should look for.

Choose one page and one destination for the first test. Sending the result to your own email is simpler than building a database or a team notification. Keep the original URL and retrieval time alongside the summary. A summary without its source is difficult to verify and easy to misinterpret.

The important distinction is whether you need a snapshot or a change alert. A snapshot can run on a schedule and summarise the current page. A change alert needs a stored previous version, otherwise Claude will rewrite the same information every time.

For more context, read Connect Claude to Google Sheets Without Writing Code.

Use Make as the default no-code option because the workflow maps cleanly to separate modules: schedule, HTTP request, text cleanup, Claude, and delivery. You can see the output between modules while testing, which makes an extraction problem easier to diagnose than one large AI step.

Create a new scenario in Make and add a scheduler, then an HTTP module that retrieves the page, an Anthropic module for Claude, and an email or document module for the result. Module names and available Anthropic actions can change, so select the current Claude action in your Make account rather than copying an old tutorial exactly.

Zapier can work when you already use it and only need a simple trigger, AI step, and destination. n8n is more flexible for branching, retries, and storing previous page versions, but its extra options create more places for a first workflow to fail. A self-hosted n8n setup also introduces maintenance that this job does not require.

Use the smallest workflow that proves the page can be fetched and understood. Add change detection, multiple URLs, and error notifications only after one page produces a trustworthy result.

For more context, read Connect Claude to n8n: 3 Workflows to Try This Week.

Fetch the page with Make’s HTTP module using a GET request and the page’s full HTTPS address. Follow redirects if the module offers that setting, and leave the request body empty. Run the module once and inspect the returned status, headers, and body before adding Claude.

A successful HTTP request does not guarantee useful content. A response can have a successful status while containing a cookie wall, a bot-check page, a login form, or only the shell of a JavaScript application. Search the returned body for a sentence you can visibly read in a normal browser. If the sentence is missing, the problem is retrieval, not prompting.

Do not try to bypass authentication, access controls, or anti-bot systems. Use an official feed, export, API, or permitted public page instead. Check the site’s terms and access rules before running a frequent automated fetch, especially for commercial research.

Test the request with a page that is publicly readable in a private browser window. Record the page title and final URL in the output. Those two fields help you notice when a redirect has silently sent the workflow to a generic homepage or consent screen.

Give Claude the page’s readable article text, not the entire HTML document, whenever possible. Raw HTML contains navigation labels, scripts, cookie notices, style rules, repeated menus, and hidden text. Sending all of it wastes context and gives the model more opportunities to summarise the wrong material.

After the HTTP step, use an HTML-to-text or content-extraction step available in your automation workspace. Preserve headings, paragraphs, lists, table labels, and links, but remove scripts, styles, navigation, footers, and repeated legal notices. Keep the page title and source URL as separate fields rather than mixing them into the body.

If your chosen tools cannot extract the main content, send a small test response to Claude and ask it to identify the main article text before asking for a summary. Treat that as a fallback, not the ideal design. Claude may mistake a navigation panel for the article when the page structure is poor.

Set a maximum text length before the Claude step. Very long pages should be truncated deliberately or split into sections. Tell the workflow when truncation occurred so the final summary can say that it covers only part of the source.

Ask Claude for a fixed, evidence-based format that matches the decision you need to make. A reliable prompt can say: “Summarise only the source text below. Start with a two-sentence overview. Then provide the key changes, affected people, practical implications, and unresolved questions. Use headings. Quote no more than one short phrase per point. If the source does not contain an answer, write ‘Not stated’. Do not infer facts.”

Put the page title, URL, retrieval time, and cleaned text into clearly labelled fields. Tell Claude that the text may be incomplete and that it must not use general knowledge to fill gaps. Ask it to identify promotional language, opinion, and factual claims separately when the page mixes those categories.

For change monitoring, include the previous extracted text or previous summary and ask Claude to compare it with the current text. Instruct it to report additions, removals, and wording changes, not just the current page’s main ideas. A page can change one important sentence while keeping the rest identical.

Use a low-variation writing style and a maximum length. Consistent outputs are easier to scan and compare than creative summaries that change structure on every run.

Run the workflow on a schedule that matches how often the source changes, then add change detection if repeated summaries would be annoying. A daily schedule suits frequently updated notices. A weekly schedule is usually enough for pages that change occasionally. Do not fetch a page every few minutes simply because the automation platform permits it.

For a simple snapshot, schedule the scenario and deliver the result each time. For a change alert, save the cleaned text or a fingerprint of it in Make’s stored data between runs. Compare the new result with the stored value. If the content is unchanged, stop the route before calling Claude. If it changed, send the new text to Claude, deliver the comparison, and replace the stored value.

Store the source URL with the saved content. Otherwise, changing the URL later can make the workflow compare unrelated pages. Include the last successful run time and the HTTP status in the delivery so you can distinguish “no change” from “the fetch failed.”

Do not compare raw HTML when small technical changes create false alarms. Compare cleaned text after removing timestamps, navigation, and other elements that change on every request.

The most common failure is a valid response containing the wrong content. Cookie banners, bot checks, login pages, empty JavaScript shells, and regional redirects can all look like successful fetches. Add a check for expected words or a minimum text length before sending anything to Claude. Route failures to your email instead of producing a misleading summary.

A second failure is context overload. Large pages can exceed the model input limit, become expensive, or bury the important section. Set a length limit, remove repeated content, and split long documents into chunks only when you have a clear way to combine their summaries.

A third failure is silent source drift. The page may keep its URL while changing its purpose, layout, or update frequency. Include the page title and a short extracted heading in each result, then review the workflow whenever the output suddenly becomes vague.

Treat Claude’s answer as an interpretation, not proof. Keep the source URL and retrieval date, and ask for supporting headings or short quotations. If the summary says a deadline, price, obligation, or eligibility rule changed, open the source before acting because page content and external rules can change.

Send the first results to email because it gives you a simple audit trail and makes failures visible. Format the message with the page title, source URL, retrieval time, summary, changes, and any warning about incomplete content. Add a subject such as “Page update: [title]” so repeated messages remain searchable.

Test with three deliberately different pages: a short article, a page containing navigation and tables, and a page that does not return the expected content. Check whether the workflow stops cleanly on the third case instead of asking Claude to summarise an error page. Compare the summary with the source, not with what you already believe about the topic.

Ask a practical question about every output: could you decide what to do next without opening the page? If not, change the prompt to request implications, affected sections, or a direct comparison. If the summary is too long, reduce the required fields rather than relying on a vague instruction to “be concise.”

Automate Basics can use the same testing habit for future workflows: verify each handoff separately before connecting the whole chain. A dependable page summariser is an extraction process with an AI step, not an AI prompt attached to a URL.

• Anthropic documentation (docs.anthropic.com)
• Make (make.com)

See the certifications