Automatic Broken Link Checker | n8n

The Schedule Trigger kicks off your workflow automatically without any manual intervention. This node acts as the heartbeat of your broken link checker, ensuring your site gets scanned consistently.

Setting this to run daily at midnight means you'll always have fresh data waiting for you each morning. You can adjust the timing based on your site's traffic patterns—some prefer running during low-traffic hours to minimize any potential impact.

💡 Tip: If you manage multiple websites, consider staggering the trigger times by 30-60 minutes to avoid overwhelming your n8n instance with concurrent executions.

This Set node establishes the foundation for your entire workflow by defining which website to scan. You'll configure your sitemap URL and domain here, and these values propagate through every subsequent node.

The sitemap URL points to your XML sitemap file—most websites generate these automatically through CMS plugins or server configurations. The domain value helps the workflow identify which links are internal versus external.

💡 Tip: Not sure where your sitemap lives? Try appending /sitemap.xml, /sitemap_index.xml, or /page-sitemap.xml to your domain. WordPress sites with Yoast or RankMath typically use the latter format.

Each workflow execution creates a fresh Google Sheets document named with the current date. This approach gives you a clean historical record—you can look back at any day to see what broken links existed at that moment.

The dynamic title uses n8n's date formatting to generate names like "01-17-2026", making it easy to sort and find specific reports in your Google Drive folder.

💡 Tip: The spreadsheet ID generated by this node gets passed to later steps. Make sure this node executes successfully before the workflow continues, as subsequent nodes depend on its output.

This Set node defines the schema for your broken link data. It creates two string fields that will store the source page URL and the broken link URL when issues are detected later in the workflow.

Think of this as setting up your database columns before populating them with data. The structure ensures consistency across all broken link records.

The Append Row node writes broken link data into your Google Sheets report. It's configured to add new rows to the spreadsheet created earlier, mapping your data fields to specific columns.

This node connects to the report using the spreadsheet ID generated by the Create node, ensuring data lands in the correct document each day.

After the report is created, this node moves it from the Google Drive root to a dedicated folder. Keeping reports organized prevents your Drive from becoming cluttered with daily files scattered everywhere.

Create a folder in your Google Drive called "Broken Link Checker" (or whatever name you prefer) before running the workflow for the first time.

💡 Tip: Create the destination folder in Google Drive before your first workflow run. The node needs the folder to exist—it won't create it automatically.

This HTTP Request node downloads your XML sitemap file. The sitemap contains a structured list of all pages you want search engines to index—and conveniently, all pages you want to check for broken links.

The URL comes from the Set node you configured earlier, making it easy to change target websites without modifying multiple nodes.

XML sitemaps aren't directly usable in n8n workflows—they need conversion to JSON format first. This node parses the XML structure and transforms it into JavaScript objects that subsequent nodes can easily manipulate.

The conversion preserves the hierarchical structure of your sitemap, including all URL entries and their metadata.

💡 Tip: If your sitemap is compressed (gzip) or stored as a binary file, you'll need to add an "Extract from File" node before this conversion step.

Your sitemap contains multiple URL entries nested inside an array structure. This Split Out node extracts each URL entry as a separate item, allowing the workflow to process pages individually.

The field path "urlset.url" corresponds to the standard XML sitemap structure where URLs are stored inside the urlset element.

This node creates a processing loop that handles one sitemap URL at a time. While n8n processes items automatically, explicit batching provides better control over execution flow and error handling.

Processing one page per batch prevents memory issues on large sites and makes debugging easier when something fails.

💡 Tip: For sites with thousands of pages, you might increase the batch size to 5-10 to speed up processing, but watch your memory usage.

For each page in your sitemap, this node downloads the full HTML content. The next step will parse this HTML to extract all internal links that need testing.

The URL comes dynamically from the current sitemap entry being processed, using the standard loc field from XML sitemaps.

This Code node contains the intelligence of your broken link checker. It parses the HTML content, extracts all URLs using regex pattern matching, and filters out CDN resources, API endpoints, and static assets that don't need checking.

The JavaScript code handles deduplication and ensures only relevant internal links pass through to the testing phase.

Code Logic:

• Extracts the HTML from $input.item.json.data
• Gets your domain from the Set Domain node
• Uses regex to find all URLs in href and src attributes
• Deduplicates results using a Set
• Filters out CDN patterns (cloudflare, cloudfront, googleapis, etc.)
• Excludes static assets (.jpg, .png, .css, .js, etc.)

💡 Tip: You can customize the cdnPatterns array in the code to add additional patterns specific to your site's architecture.

After extracting links from all pages, this Merge node aggregates everything into a single list. This consolidated dataset then gets sent to the sub-workflow for actual link testing.

This HTTP Request node sends all extracted links to a separate webhook-based sub-workflow that handles the actual link testing. Splitting the architecture this way keeps the main workflow clean and allows the testing logic to run independently.

The payload includes both the spreadsheet ID (for logging results) and the complete list of links to test.

💡 Tip: Replace the webhook URL with your own n8n instance URL. The path "/webhook/brokenlinkcheck" should match the path configured in your sub-workflow's Webhook node.

This Webhook node starts the sub-workflow that actually tests each link. It receives the data from the main workflow and kicks off the link-checking process.

The webhook listens for POST requests and passes incoming data to the subsequent nodes for processing.

💡 Tip: The Test URL shown in the interface is for development testing. In production, use the Production URL which becomes active when the workflow is activated.

This node extracts the link data array from the webhook payload body. It isolates the "body.data" field containing all URLs that need testing.

Each link needs individual testing, so this node creates a loop that processes one URL at a time. This prevents timeout issues and allows for proper error handling on each link check.

This is where the actual link testing happens. The node sends HTTP HEAD requests to each URL—a lightweight method that checks if a resource exists without downloading its content.

HEAD requests are perfect for link checking because they're fast and consume minimal bandwidth while still returning the status code you need.

💡 Tip: The "Ignore SSL Issues" option is enabled to handle sites with expired or self-signed certificates. While this might flag some false positives, it ensures the checker doesn't fail on SSL-related issues.

This conditional node examines each HTTP response. If the status code isn't 200 (OK), the link is considered broken and routes to the logging path. Links returning 200 skip the logging step entirely.

The node catches 404s (not found), 500s (server errors), 301/302s (redirects that might indicate issues), and any other non-success status codes.

When a broken link is detected, this node appends a row to your Google Sheets report. Each row contains the source page where the broken link was found and the actual broken URL.

The spreadsheet ID comes from the webhook payload, ensuring results land in the correct daily report.

After all links have been tested, this node consolidates the results into a single output. This aggregated data gets returned to the webhook caller.