Planned vs Observed Internal Links

Paper Route, an imaginary custom-notebook shop, is replacing scattered ordering instructions with a clearer website library. Its editor has proposed links, a developer has implemented some changes, and a reviewer has checked only part of the release. This guide follows that uneven, realistic handoff rather than treating every green-looking record as independently verified completion.

Agree on what each state actually says

Use planned for an intended directed relationship, observed for a user-recorded observation, and both when that same relationship is planned and recorded as observed. Both is not a higher-confidence badge. It preserves two meanings at once. The planner does not inspect the source, test the destination or require supporting evidence before accepting an observed entry. Explain this vocabulary to everyone reviewing the map before assigning implementation tasks.

At Paper Route, the customization overview should lead to artwork preparation. Before implementation, that record is planned. When a reviewer later records seeing the relationship, both can retain the original planning meaning alongside the observation. An existing link discovered during a manual inventory can simply be observed when no planned status is being asserted. Choose the state for its actual meaning, not to make the diagram look more complete.

Page stage is independent. A source marked published may have no observed link records because nobody has entered any. A draft can contain a planned relationship to another draft. Updating a destination from idea to published does not implement its incoming links. This separation helps during staggered launches: the content can be ready before its navigation is installed, or the navigation can be proposed while the destination still needs editorial approval.

Agree on a lightweight team convention outside the schema: who performs checks, which environment counts for the release, and where longer records live. The evidence field can hold a short account, not a complete approval system. There are no built-in reviewer, timestamp or expiry fields. Put those details in evidence or notes when useful, and preserve a fuller history in your normal work tracker rather than assuming the map supplies one.

Freeze a small inventory before checking relationships

Paper Route starts with five resources: the customization overview, artwork preparation, paper choices, proof approval and repeat orders. Each has a stable page identifier and a distinct intent. That bounded list makes a review achievable. One project allows up to twenty-four pages and ninety-six directed links, but a relaunch need not use every slot. Include the pages necessary to understand the release and state what the working set deliberately leaves out.

Set the website origin before entering paths. The origin is an absolute HTTP(S) origin without credentials, a section path, query or fragment. A page address may be blank, root-relative or absolute on that same origin. The tool does not request any of them. If the shop tests on a separate staging origin, keep its inspection context clear instead of entering off-origin staging addresses as though they were production page URLs.

Check duplicate normalized URLs before dividing the workload. Two fragment variants of the artwork-preparation page still identify one page in this comparison. Path case, query order and trailing slashes remain significant; the planner does not guess redirects or aliases. A duplicate finding might reveal two records for the same resource, but it does not invalidate the whole project. Resolve the record ownership so reviewers do not report against different names for the same destination.

Save a dated JSON snapshot when the review set is agreed. Make the filename and accompanying work ticket identify the release, because the project title alone is not a change history. Incomplete titles, intents and URLs can remain in a structurally valid export, but label the unfinished work honestly. A blank destination address tells the implementer that placement is not ready to confirm; inventing a plausible path would hide a real dependency.

Write planned records that an editor can implement

A useful planned record gives the editor a source, destination and concrete wording. Paper Route chooses customization overview to artwork preparation with the anchor Prepare your notebook artwork. The team adds After file requirements summary; release ticket PR-42 as supporting context. This is actionable without being a complete paragraph rewrite. The destination page should fulfill the promise before the link sends readers there; the planner itself does not evaluate that content.

Make the reverse decision separately. Artwork preparation might lead back to customization options, or directly onward to proof approval. Neither route follows automatically from the outward link. Each directed pair gets at most one record, and a reverse pair is permitted. If the same destination appears twice on a source page, use a separate editorial checklist for occurrence-level placement; the map cannot represent two independent records for that identical source-target pair.

Keep anchor text reader-facing and evidence implementation-facing. An anchor such as Approve a notebook proof tells an editor what readers should see. Evidence such as Add beside approval deadline describes where the work belongs. Descriptive wording and a relevant surrounding sentence help set expectations; repeating an internal ticket number as visible link text does not. Read the proposed sentence in context before assuming that a clear field value produces a clear website passage.

The hub round-trip action can intentionally create a starting set of plans between the chosen hub and every other page. It preserves existing evidence and observations, upgrading observed pairs to both. It does not install those links or replace editorial judgment about every return route. Capacity is checked atomically within the ninety-six-link limit. Review the generated relationships and remove an unnecessary plan deliberately rather than assigning implementation just because a button created the record.

Make observations outside the planner and record their limits

Open the relevant website page in your normal review environment, not through the planner’s URL field. Read the source passage and inspect the destination it actually presents. If following the link, check that the resulting resource matches the wording and intended task. This is a manual review procedure performed outside the tool. A record entered afterward describes what you checked; it does not cause the planner to repeat the inspection or retrieve a status code.

Use compact evidence that answers practical questions. For example: 23 Oct, public overview, file requirements paragraph, artwork guide reached; reviewer LM. That distinguishes a public-page check from a preview-only approval. The two-hundred-character allowance is enough for a summary, not an archive. Reference a ticket for screenshots or unusual redirect behavior, and avoid stuffing unrelated launch commentary into every link record where it obscures the actual observation.

Record the anchor wording you intend to track, then note any mismatch worth resolving. If the public page says More information while the plan says Prepare your notebook artwork, the source-target relationship may exist even though the requested wording remains unfinished. Both cannot express separate completion states for destination, wording and placement. Explain the outstanding detail in evidence and the work ticket instead of reading the combined state as approval of every editorial requirement.

Do not turn an inability to inspect into an observation of absence. A reviewer who cannot access a preview has learned something about their access, not whether the requested link exists. Leave that uncertainty in the page notes or task record. Likewise, empty evidence is allowed but communicates little. When an old observed entry lacks context, ask for a fresh check rather than presenting the label alone as current, independent verification.

Interpret counts and paths without expanding the claim

The matrix records P for planned, O for observed and B for both. A dash means no entered record for that direction. It is not the result of a live negative check. Suppose proof approval points to repeat orders on the website but nobody enters that pair. The dash describes the inventory, not the website. Add the relationship after a scoped manual check rather than treating every empty cell as an instruction to insert another link.

Observed incoming and outgoing counts include both-state links. Planned-only counts exclude both. Read the labels carefully when comparing implementation work with the recorded observed network. A project with eight observed relationships and three both-state relationships does not necessarily contain eleven observed relationships: the both group is already included in observed. Use the separate planned-only figure when estimating relationship requests that have no recorded observation attached.

A published non-hub page without recorded observed incoming links deserves investigation within this working set. It may receive live navigation links outside the inventory, have planned links awaiting implementation, or simply lack an entered observation. Those possibilities lead to different tasks. The finding is not a site-wide orphan diagnosis. Similarly, an all-link isolated page has no entered planned or observed connections at all, which says something different about the state of this map.

Observed reachability follows direction from the selected hub through observed and both records. A support page pointing home does not establish a path from the hub to that support page. When no hub is selected, reachability is unknown rather than failed. Paper Route may have a connected-looking diagram but an outward route still missing from the recorded observed network. Check arrow direction and state before proposing content work to solve a presentation misunderstanding.

Check a release in dependency order

Separate content readiness, link installation and observation into three review passes. Paper Route first approves the artwork guide and proof instructions. Next, an editor adds relevant relationships in the content management system. Finally, a reviewer inspects the public passages and updates the dataset. Combining those passes into one vague Done status makes it harder to locate the remaining task when a destination is ready but the incoming link has not been implemented.

Begin with paths that the release actively promises. If the overview tells customers to prepare artwork before ordering, its preparation route deserves attention before an optional paper-history reference. Prioritize by the consequence of an unresolved visitor task, not the node’s visual position. The graph does not calculate business urgency, diagnose lost traffic or predict rankings. Its job is to make entered relationships inspectable so the team can assign sensible next actions.

Give each reviewer a bounded set of source pages, not a broad instruction to check all links. The overview reviewer checks outgoing routes to preparation and paper choices; the proof reviewer checks the next-step relationship to repeat orders. Compare the resulting checklist against the agreed scope afterward. A source-oriented assignment makes it easier to read links in their actual paragraphs and to notice when proposed wording no longer fits after an editorial revision.

Mark the page stages and link states separately at handoff. A published proof guide can retain a planned-only onward relationship if the repeat-order resource is unfinished. Do not upgrade that link merely to close the release ticket. Explain the deferred dependency, revise any public promise that cannot yet be fulfilled, and assign the next check. Exporting a polished PDF is useful for review, but it does not change the implementation status of anything in it.

Re-record changes without inventing a live history

An observation belongs to the circumstances recorded with it. Rewriting the customization overview next month can remove a link that was present at launch. Nothing in the planner notices that change automatically. Schedule a manual review in your team’s existing workflow when a relevant source or destination changes. The evidence text has no automatic expiry calculation, and a recent project export does not make every observation inside it recent.

When a fresh check finds a removed relationship that the team still wants, save the historical snapshot and return the current record to planned with a clear new instruction. If the relationship is intentionally retired, remove its current record and document the decision elsewhere if needed. Both must not stand for once observed but now absent. It means planned plus user-recorded observed, so use the current working file consistently with the convention agreed by the team.

Absence has no dedicated link state. A dash can mean unrecorded, out of scope or intentionally omitted, so explain a checked absence in the relevant notes or work ticket rather than expecting the matrix to encode it. For example: Public overview checked 30 Oct; proof route intentionally removed after journey revision. This preserves the reason without creating a false destination relationship simply to hold a negative result in the link list.

For changed addresses, distinguish a page-record correction from a website migration. Updating the URL in the project does not add a redirect, edit existing website links or inspect canonical declarations. Check those website behaviors separately. Retain stable record identifiers where the same editorial resource continues to exist, and inspect related evidence after a substantive move. A note describing an old path can remain historically understandable while no longer supporting a current placement claim.

Deliver a review packet that preserves uncertainty

Use editable JSON as the working handoff and save it intentionally; there is no autosave or stored project library. Version-one input must match the required schema and fit within one MiB of UTF-8 JSON. It is not a website export importer. Share a dated file and identify the owner of the next revision so two reviewers do not independently update copies and mistake them for a merged source of truth.

Send Pages CSV and Links CSV when a recipient needs selectable tabular text. These exports quote fields, include a byte-order mark and use CRLF line endings with spreadsheet-formula neutralization. JSON preserves the originals. CSV cannot be imported back into version one, so do not promise a spreadsheet review will automatically become the next project. Agree whether the owner will manually reconcile edits and how unresolved comments will be carried forward.

Choose the PDF for a readable review packet containing the map, complete page inventory, explicit relationships, evidence and contextual next steps. It is rasterized rather than a selectable-text database, and it is bounded at forty MiB and fifty pages. The PNG is an abbreviated map with a longest-edge limit of 4096 pixels. Neither visual format should be treated as the complete editable record or proof that the pictured links currently exist.

Before sending, read the packet as someone who did not attend the release meeting. Can they tell which relationships await implementation, which observations lack evidence and which pages were outside the review? Add missing context without claiming complete site coverage. Copy checklist is useful for a compact assignment, but confirm clipboard success and retain JSON too. A useful handoff makes uncertainty actionable instead of hiding it behind a diagram that happens to look connected.

Questions about Planned vs Observed Internal Links

Continue with another content planning guide

Build your next page and link map in the Content Hub & Internal Link Planner, or choose a focused guide below. More browser-based helpers are in the free tools directory.