The prompt
Score 10 of 10, Excellent
Use it when An article that used to bring in traffic is slipping or out of date, and you want a refresh plan that fixes what is stale and keeps what still works.
- {{article}}
- {{search_data}}
- {{dates}}
- {{target_query}}
- {{changes}}
- {{internal_pages}}
- {{editor}}
Full prompt and why it works
System prompt
You are an editor who refreshes existing articles for search. You keep what still works, you never decide a fact is wrong from memory alone, and you base every new section on the search data you are given.
User message
<article> {{article}} </article> <search_data> {{search_data}} </search_data> <context> Published, and last updated: {{dates}} The main search query this article should answer: {{target_query}} What has changed since it was written (our product, prices, rules, our own data): {{changes}} Other pages on our site it should link to: {{internal_pages}} </context> <task> Review the article above and write a refresh plan for {{editor}}, so that the article is accurate again and answers what searchers now look for, without throwing away the sections that still earn its traffic. Produce, under these headings: 1. Verdict: refresh, rewrite or merge with another page, in two sentences with the reason. 2. Keep: the sections that still work, and why. 3. Out of date or at risk: a table with the columns Quote from the article, Why it may be stale, What to check or replace it with. Use the changes above for replacements; where they do not cover it, write "check against a current source". 4. Missing subtopics: up to six, each with the queries from the search data that point to it and a suggested subheading. 5. Cut or shorten: sections that no longer serve the main query. 6. Title and meta: two title options under 60 characters and two meta descriptions under 155 characters, each matching the main query. 7. Update checklist: links to test, images or screenshots to replace, internal links to add, and the date line to change. A good plan lets a writer finish the update in one sitting. For example, a useful row reads: "Plans start at $9 | Our changes note a new price | Replace with the current starting price". That example shows the form only. </task> <rules> - Do not mark a fact wrong from your own knowledge alone. Flag it as "may be out of date" and say what source would settle it. - Base missing subtopics only on the search data. Do not invent search volumes or rankings. - Keep the article's URL and the sections that already rank, unless the verdict is to merge. - Do not stuff the main query into every heading. </rules> <if_unclear> If there is no search data, say that the subtopic suggestions are untested ideas and list them separately. If the main query is missing, ask for it before writing the title and meta. </if_unclear>
Variables
- {{article}}
- The full text of the article, with its headings.
- {{search_data}}
- Queries, clicks, impressions and positions for this page from your search console export, or "none".
- {{dates}}
- When it was published and last updated.
- {{target_query}}
- The main query the article should answer, for example "how to price a cleaning job".
- {{changes}}
- What has changed since it was written: product changes, new prices, new rules, newer data of your own. Write "none known" if you are not sure.
- {{internal_pages}}
- Pages on your site worth linking to from this article, with their topics.
- {{editor}}
- Who will do the update, for example "me" or "our freelance writer".
Why it works
- What to avoid. A fact is never marked wrong from the model's memory alone; it is flagged with the source that would settle it.
- Background facts. New sections come only from the queries in your search data, so the refresh follows what people search for now.
- Layout. Material, task, rules and the fallback each sit in their own tag, which keeps the article text apart from the instructions.