Turn the proposal into a reader task
Write the proposed reader, their starting situation and the decision or action they should be able to complete. A keyword or attractive title alone does not define a useful page. Ask the requester for the question they cannot currently answer using the site, and record where that question came from without including private customer information.
Keep the evidence proportionate. An anonymized support theme, an observed gap in a procedure or a repeated internal question can motivate investigation. None automatically proves broad demand. Distinguish the observation from your interpretation, and state what remains unknown before committing writing time.
Compare the answer, not just the title
Find existing and planned material that could satisfy the same task. Read the relevant sections and note the audience, prerequisites, scope and resulting action. Two differently named articles may answer the same question, while similar titles may cover different workflows. Include unpublished briefs so the editorial queue does not recreate work already assigned.
Create a short comparison record: proposed task, closest existing resource, missing information and recommended action. If an existing page needs one clarification, adding a focused section may be enough. If the proposed procedure has different prerequisites and a complete independent outcome, a separate resource may be easier to use and maintain.
Choose a publication decision with a reason
Use three practical outcomes: update an existing resource, create a distinct page or defer the proposal. An update is appropriate when the same reader task remains central. A new page needs its own coherent purpose and enough supported material to fulfill it. Defer when the question is already answered or essential evidence is unavailable.
Google’s guidance emphasizes helpful, reliable content for an intended audience and additional value rather than a preferred word count. Do not pad a weak proposal to meet a length target. Specify what the new page contributes, such as a tested procedure, a decision record or a worked example clearly identified as illustrative. Never invent experience to justify publication.
Illustrative example: a question within a checklist
Imagine a preparation checklist already tells readers which files to gather before a site review. A proposed article would explain only the preferred filename format for those same files. The editor records that a short addition to the checklist answers the question in context. This fictional example illustrates a decision, not evidence of customer behavior or search performance.
A separate proposal explains how to obtain an authorized export from a specific system, with its own access requirements and verification steps. It could justify a separate tutorial if the team can verify those steps. The decision is conditional on evidence; a promising title does not make an untested workflow ready to publish.
Leave a decision someone can revisit
Record the chosen action, owner, closest related page and the evidence required before drafting. If you defer, specify what could change the decision: a verified workflow, a changed product feature or a newly documented reader need. This prevents the same unsupported proposal from returning under another title.
After writing, test whether the resource actually answers the original task without requiring an unnecessary second search. An SEO audit can help inventory current pages, but it cannot replace reading and comparing their answers. Reassess the page decision if the draft repeats an existing resource. Approval to investigate a topic is not a promise to publish it or a prediction of rankings.