Split, merge and combine decisions
Change the structure only after choosing the answers to preserve.
A split gives distinct reader tasks their own destinations. A merge combines material that belongs in one maintained answer. Consolidation includes the content work and, when URLs change, the technical and navigation work needed to carry readers to the chosen destination. Length alone does not decide any of these actions.
Free learning from Semantec SEO.
Define the task boundary before comparing length.
Write the reader need, expected outcome, audience and conditions for each candidate. Compare required evidence, answer form and next action. Two short texts can complete distinct tasks, while a long resource can still contain one coherent answer.
Keep an explanation together when its definitions, qualifications and example must be read as a unit. Consider a split when a task has a different audience, evidence burden, maintenance schedule or useful next action and can stand alone without copying the parent answer.
A topic label is not a boundary by itself. “Greenhouse watering” could contain understanding a system, comparing requirements, diagnosing a fault or requesting a service. Decide which of those tasks the candidate actually completes before allocating a URL.
Read the existing material and its dependencies.
Gather the current body, media, tools, sources, known internal links, external references where available, fragment targets and technical state. Identify later edits and source conditions before copying content into a proposed destination.
Create a retention record for each useful definition, example, qualification and source. Mark what stays, moves, is summarized or is removed with a reason. Removing repeated phrasing does not justify losing the only explanation of an exception.
A working interactive tool needs its own behavior and service review before a structural change. For the editorial decision, keep task, evidence, retained material and review fields together in a record that another person can inspect.
Worked example: three short explanations.
A fictional educational site has three short resources: “What a greenhouse site record contains”, “How to record light conditions” and “How to record access constraints”. The example is invented and does not provide horticultural or building advice. No search effect is measured.
First compare their tasks. Suppose the first only introduces the same site record, while the next two each describe one field within it. Neither focused resource provides enough independent evidence or a distinct next action to justify a separate destination in this scenario.
Next inspect their useful material. Keep the record definition from the first, the observation example from the second and the access qualification from the third. Assemble a proposed resource that explains the record, covers both fields near their conditions and uses one complete example.
Then check the decision against an alternative. If the light question instead requires a detailed specialist method, its own examples and a different source review, it may deserve a separate resource. The combined page can summarize the prerequisite and link to that answer. Three short texts do not automatically mean either three pages or one page.
| Existing explanation | Useful material to retain | Proposed destination in this scenario |
|---|---|---|
| Site record definition | Purpose, fields and scope | Opening explanation in the combined resource |
| Light conditions | Observation example and evidence limits | Named content block beside the relevant field |
| Access constraints | Qualification that changes the plan | Named content block with a clear link target |
Test the proposed structure against the evidence.
Ask if the assembled answer completes one task without repeated introductions or abrupt changes of purpose. Check that each retained claim keeps its source, date, scope and qualifications. A source about one material, market or version must not be generalized during the move.
Review the proposal with an appropriate subject source and another editor. If the task is unclear or the evidence is inconsistent, hold the structural change. A temporary registry state is safer than publishing a confident but unsupported replacement.
Search observations can inform a review of current destinations, but a content decision is not a guaranteed traffic intervention. Keep the intended reading improvement separate from any later change in impressions, clicks or rankings.
Use a static decision record.
Use the fields below to keep a decision record in your own document. Record the evidence and unresolved questions beside the proposed action so the reviewer can inspect the full context.
| Field | What belongs in the record |
|---|---|
| Record ID and candidate topics | Stable identifier and the current URLs or task labels |
| Task equivalence | Same decision, related decisions or distinct reader jobs |
| Entity and attribute scope | Subjects, properties, relationships and exclusions |
| Evidence and answer form | Sources, examples, required comparison or explanation |
| Retained material | What stays, moves or is removed, with reasons |
| Decision and state | Retain, revise, combine, split or hold for evidence |
| Owner, date and next route | Accountable reviewer, review date and next check |
Plan the routes before retiring a URL.
A merge proposal must name the final destination and how existing references will reach the retained answer. Check internal links, navigation, breadcrumbs, fragment identifiers, source citations, sitemap entries and any reusable brief that names the old route.
If a URL is retired, plan an appropriate redirect only after checking that the destination serves the old reader need. Do not send unrelated retired answers to a homepage or a broad hub merely to avoid an error response. Keep the redirect and rollback records tied to the current site state.
A canonical annotation is a signal for duplicate or very similar documents; it does not redirect visitors. A redirect changes the route. Neither mechanism removes the need to preserve useful content or resolve distinct tasks. Google’s canonicalization documentation explains the technical distinction and signal context.
Check migration dependencies in order.
Prepare and review the destination first. Confirm that sources, examples, media and content block ids are present. Verify its template, title, description, status, canonical output and public availability before changing incoming routes.
Apply route changes through a supported site process with an exact change record. Update relevant internal links to the intended destination, then test each affected source URL and fragment. A successful editor save does not prove the public page or redirect behaves as intended.
Record the old and new destinations, retained materials, link changes, technical changes, review evidence and recovery reference. Reconcile an uncertain write before repeating it. Observe later search records under comparable filters rather than assuming every fluctuation came from the migration.
Know when to keep separate answers.
Keep distinct resources when the tasks differ materially, even if one is short. A pricing comparison and a cancellation process can be related but need different facts, qualifications and next actions. Provide a useful cross reference without collapsing them into a confusing mixed task.
Do not merge content merely to reduce the page count. Do not split content to meet a publishing target. If the best structure is unclear, retain the current supported answer and record the missing evidence before making a route change.
Use overlap diagnosis for the initial comparison and page or content block decisions for smaller boundaries. Return to the topical mapping overview or the learning overview.