How it works
What this workflow does
Find pages that are losing organic search clicks before the decline becomes obvious in a monthly report. A weekly schedule queries Google Search Console for the latest 28-day window and the preceding 28 days, compares pages that appear in both periods, and queues meaningful drops in Google Sheets with both traffic totals and the size of the loss.
The workflow imports inactive with dryRun: true. Run with sample data compares a fictional baseline and recent fixture, so the preview does not call Search Console or Google Sheets.
This is a search-performance review layer for the Campaign Launch Assurance & Weekly Performance blueprint; the Content Publishing & Newsletter Intelligence blueprint covers the content refresh that follows.
Use finalized comparison windows
Plan Search Console comparison requires the exact Search Console property and spreadsheet ID. It builds two 28-day windows with a configurable finalDataLagDays (four by default), so the query avoids incomplete recent data. Both API requests use dataState: "final" and the page dimension.
The baseline query and the recent query are validated as URL, click, and impression rows. Duplicate or malformed pages stop the run. If either response reaches the configured row limit, the workflow stops instead of silently comparing a truncated report.
Flag only meaningful declines
A page must appear in both periods and meet all three defaults: at least 30 baseline clicks, at least 15 lost clicks, and a 25 percent drop. The queue row records the baseline and recent clicks and impressions, the lost click count, the drop percent, and the period end. Findings are sorted by the largest click loss.
Pages that existed in the baseline but are absent from the recent response are counted in missingFromRecent but are not added to the decline queue. Search Console can omit rows, so investigate those pages independently.
Replays and validation scope
The Finding ID combines the period end and page URL. Running the same period again updates the same review rows; a new period creates a fresh set of findings.
The supplied report confirms the isolated n8n 2.47.4 import, inactive state, and sample path. It also covers structural checks, the 50 percent decline fixture, omission handling, and row-limit rejection. Live Search Console and Google Sheets calls require a staging test with your accounts.
How to use
Before you start
- A current n8n instance.
- A Google Cloud project with the Search Console API enabled.
- A Google account that can read the Search Console property.
- A Google spreadsheet tab for the review queue.
- A Google Sheets OAuth credential.
1. Import and run the sample
Download the complete package, extract the ZIP, and read the full setup guide. Import search-content-decay.n8n.json and keep it inactive.
Open Run with sample data and choose Test workflow. Compare search performance should flag one page with a 50 percent click decline and keep the other fixture pages out of the queue.
2. Configure the property and sheet
Enter the exact Search Console property in Setup, such as sc-domain:example.com or https://www.example.com/, and the destination spreadsheetId.
Create a tab called Search Review Queue with these exact headers:
| Finding ID | Page | Period End | Baseline Clicks | Recent Clicks | Lost Clicks | Drop Percent | Baseline Impressions | Recent Impressions |
|---|
Select the Google Sheets OAuth credential on Save organic review queue.
3. Configure Search Console OAuth
Create a generic OAuth2 API credential for Google with the https://www.googleapis.com/auth/webmasters.readonly scope. Use Google's authorization and token endpoints and an account with access to the property. Select it on both Search Console HTTP nodes.
Enable the Search Console API in your Google Cloud project before the first live run. The property string must match Search Console exactly; a URL-prefix property and a domain property are different values.
4. Tune the thresholds
Set the workflow timezone and review the defaults in Setup: minimumBaselineClicks 30, minimumLostClicks 15, minimumDropPercent 25, finalDataLagDays 4, and rowLimit 5000. The comparison uses two 28-day windows ending before the configured lag.
Run a scheduled staging test before activating the weekly Monday 08:00 report. Confirm the dates, the property scope, and the queue rows.
5. Review the findings
Use the supplied test payloads to check the baseline and recent shapes. Repeating the same period updates the same finding rows; a new period creates a fresh set of review items.
A click decline is a review signal. Check comparison dates, impressions, search position, and recent site or search changes before editing a page. If either window reaches the row limit, narrow the page scope or increase the limit within the API maximum.
Related automations
Use the Source-Backed WordPress Draft System to refresh a declining article with cited sources, then the Article-to-Social Draft System to distribute the updated piece. The Industry News Digest System keeps the team aware of search and advertising changes, and the Company Positioning Brief System keeps the page aligned with the audience. Read the Campaign Launch Assurance blueprint for the wider performance process. For recurring revenue reporting, use the HubSpot Weekly Sales Pipeline Digest.