Decide which old blog posts to refresh, merge, or leave

Build me an app my content team opens at the start of every refresh cycle to decide which of our own published articles to update, merge, or leave alone. It replaces the spreadsheet ritual where we export every blog URL, paste in metrics, and score each post by hand. It uses BuzzSumo for the research, Asana for the work that comes out of it, and Google Sheets as the decision log.

Settings the app needs, saved and editable in the app: our site domain (for example ourcompany.com), the Google Sheet ID and tab name for the decision log, and the Asana workspace and project where refresh tasks are filed. Optionally a lookback window, defaulting to everything published more than six months ago.

The main view is a sortable table of our own articles, fetched with BuzzSumo Search Articles using a site: query on our domain (q = site:ourcompany.com). Columns: article title linking to the URL, publish date, total engagement (sum of the Facebook, Twitter, Pinterest, and Reddit share fields BuzzSumo returns), evergreen score, number of linking domains, decay score, and current verdict if one was already logged. Every column sorts, and the table opens sorted by decay score worst first. Let me filter by publish year and by whether an article has been reviewed.

The decay score is a transparent 0 to 100 number where higher means it needs attention sooner. Compute it from what BuzzSumo actually returns: months since publish, engagement relative to the median engagement of the articles in the fetched set (well below median is the strongest decay signal), a low evergreen score, and the number of linking domains, which raises priority rather than lowering it because a heavily linked post that is slipping is the most valuable thing to fix. Once I have opened an article's detail panel, fold in the count of newer competitor pieces on the same topic and raise the score accordingly. Show the component breakdown in a tooltip or small popover so nobody has to trust a black box, and keep the weights in one place in the code so they are easy to tune.

Quota is the hard design constraint. Paid BuzzSumo plans include only about 100 Search API calls per month, so the app must never search on render, on mount, on tab focus, or on any automatic interval. Every search runs only when I press an explicit button. Cache the article list per domain and cache each article's detail results per URL, both persisted server side so a page reload does not refetch. Show a clear as of timestamp next to any cached result, with a Refresh button beside it that spends a call only when I choose to. Keep a visible counter of how many searches this app has spent in the current calendar month so the team can see the budget draining, and warn me before an action that would spend several calls at once.

Clicking a row opens a detail panel for that article. On first open, and only behind a Load live data button, it runs three things: BuzzSumo Get URL Share Counts for the article's current numbers so I can compare them against what the table shows, BuzzSumo Search Backlinks for that URL to list who links to it with each linking page's authority, and a second BuzzSumo Search Articles call for newer competitor coverage of the same topic. Build that competitor query from the article's main topic keywords plus -site:ourcompany.com to exclude ourselves, with a begin_date around the article's publish date so it only returns pieces published after ours. Note that BuzzSumo date parameters are Unix timestamps in seconds, not ISO strings. Cache the whole panel per URL with its own as of stamp, so reopening a row I already loaded costs nothing.

From the detail panel I set a verdict of Refresh, Merge, or Leave, with a free text reason. Refresh creates an Asana task with Create a Task in the configured project, titled after the article, with a description containing the article URL, the competing pieces the panel surfaced with their engagement numbers, the decay score, and my reason. Show me the created task link in the panel afterward. Merge and Leave create no task, only a log entry, though Merge should let me name the target article we would merge into and include that in the log.

Every verdict, whatever it is, appends a row to the Google Sheets decision log with Append Values: article URL, title, publish date, decay score at review time, verdict, my reason, the merge target if any, the competitor URLs cited, the Asana task link if one was created, who reviewed it, the review timestamp, and a cycle label such as 2026-Q3. On load the app reads that log back with Get Values and uses it as memory: any article with a logged verdict is treated as settled and hidden from the main queue by default, so the board never re-surfaces something we already decided. Include a Show reviewed toggle that reveals settled articles with their verdict and reason visible, and let me deliberately reopen one if circumstances changed. Because each review is stamped with a cycle label, starting a new cycle can optionally clear the slate and reconsider older verdicts.

Be honest in the interface about what this data can and cannot tell us. BuzzSumo measures social engagement and backlinks, not search traffic, so the app must never imply it detected a traffic drop. Put a short line of copy near the decay score explaining that the signal is falling shares plus newer competitor coverage of the same topic, and that a rewrite decision should be confirmed against our own analytics. Also keep in mind that BuzzSumo searches cap at roughly 1,000 records (10 pages of 100), so for a large archive let me narrow by publish year and audit in slices rather than silently truncating.

Handle the failure cases plainly. If BuzzSumo returns a quota error, say the monthly search allowance is exhausted and keep showing the cached results with their as of timestamps instead of blanking the screen. If the decision log sheet is empty or missing headers, write the header row on first use.