Update a Page or Write Another by Comparing the Reader Tasks

Update an existing page when the missing answer belongs to the job it already promises. Write another page when the reader needs a different outcome, evidence or workflow. Start by comparing those jobs and the actual pages, rather than counting keywords or changing the publication date.

Your next article idea sounds useful. Then someone finds an older page with almost the same title. Should you improve that page, publish the new draft, or merge the two? For a small team, the choice also determines which example needs maintaining and where a future reader should land.

A shared topic is only a starting point. Two pages about analytics can solve different problems, while two differently titled articles can repeat the same answer. Before opening a blank document, read the existing page as a person trying to finish the proposed task. Decide what the new work would let that person do.

Compare the promised task with the missing answer

Write the proposed reader job in one sentence: “After this page, a founder can check whether a reported traffic decline compares equivalent periods.” Then describe the existing page the same way. Include the intended audience, starting situation and useful outcome. A title or a list of shared keywords does not establish that the promises are equivalent.

Read the body, examples and final action. An old page may have the right headline but omit the step a reader needs. Conversely, a general introduction can mention a subject without serving as a complete diagnostic guide. Record the specific section that answers the task, or the specific gap preventing completion.

Use this distinction to define the revision. If an existing tutorial teaches how to set up a form, and its screenshots show an outdated button, the missing work is a current walkthrough for that tutorial. Another article with a slightly altered title would leave the original instructions wrong. Update the steps, verify the changed route and record what was revised.

If the proposed topic is how to recover from a failed verification email, the existing setup tutorial may provide context without answering the recovery task. That could justify a separate page with failure cases and a clear return path. Link it from the point in the setup tutorial where a reader encounters the problem.

Google's helpful-content guidance asks whether a page supplies original value and helps its intended audience achieve a goal. It also cautions against changing dates without substantial changes or adding content merely to make a site seem fresh. Use the gap in the answer to justify the work, rather than a calendar label.

Three editorial choices for a fictional content library

Consider a deliberately invented small software site's content inventory. These are worked editorial decisions, not customer performance results.

Update the existing page: a booking setup guide still describes the previous timezone control. The audience, starting task and intended result remain the same. Replace the inaccurate step, add a verified current example and check the remaining instructions. Keep a note of the substantive change; do not describe a spelling correction as a new investigation.

Create a linked companion: that same site wants to explain how a team chooses which timezone owns a recurring release. This is a decision before entering the schedule, with different examples and an operator handoff. A separate guide can answer it directly, while the setup page links to it at the relevant setting. The new page needs a complete answer of its own.

Review a possible merge: the inventory contains two short pages called “Add a booking link to your site” and “Put your scheduling link on a webpage.” Both assume the same audience and teach the same copy-and-paste task. Compare the actual steps and useful exceptions. If one maintained destination can preserve everything the readers need, consolidation is a candidate. The titles alone are not enough to decide.

This map is a planning aid. It is not a ranking forecast or proof that overlapping keywords damage either page. If you have search and usage evidence, examine it alongside the content before changing an established destination. Preserve useful exceptions that serve different readers instead of compressing them out of the library.

A real pair of related guides that should stay separate

Our published complete-days comparison guide asks whether a reported decline compares the same scope and elapsed period. Its worked example shows how fictional counts produce a different percentage when the window changes. The deliverable is a record of the website, metric, windows, freshness and next investigation.

Our UTM redirect guide starts with a campaign URL whose tracking parameters disappear along its route. It uses constructed local responses to locate the first changed hop. Its deliverable is a particular redirect or link change to inspect and repair.

Both concern analytics and can meet in one investigation. Once a fair traffic comparison points to a campaign-link problem, the first article can send the reader to the second. Combining all of their steps into one generic traffic page would obscure those different starting questions. This is a comparison of the published instructions, not evidence about their rankings or visitor behavior.

Apply the same test to your draft. Say where a reader would enter, what they would already know and what they should have in hand at the end. If those fields differ materially, a useful contextual link may serve the reader better than a merge. If the fields are the same, identify the additional evidence or method that improves the existing destination.

Keep editorial consolidation separate from URL mechanics

After a content decision, plan what happens to each URL. Keeping two equivalent URLs accessible, retiring one destination and updating one page in place are different operations. A content brief should not silently become a site migration.

Google's canonicalization documentation covers duplicate or very similar pages and signals for a preferred URL. A canonical annotation identifies a preference; it does not combine the pages' missing instructions for the reader. Resolve which content should be maintained before selecting the technical treatment.

If retiring a duplicate after a genuine merge, map the old URL to the relevant complete destination. Google's URL-change guidance recommends permanent server redirects where possible, updating internal links and testing the mapping. It warns against sending unrelated old pages to a generic homepage. Give that implementation to the person responsible for routing, with the exact old and target addresses.

For a straightforward update, verify the same public URL after deployment: the corrected step, example, working links and displayed revision information should agree. For a companion, check both directions of the contextual link and ensure the introduction explains its own task. For a merge, check that old entry links reach the intended material and that useful sections survived.

The decision is complete when you can name the reader's job, the affected URL, the substantive change and the check that will establish it worked. That gives a small team a maintainable library, with each new page earning its place through a different useful answer.