Keep Old Section Links Working When You Redesign a WordPress Page

Before rebuilding a long WordPress page, copy its known section links and record what each promises readers. Keep existing anchor IDs when the same topic survives, even if headings change. For split or retired content, approve an honest landing point before implementation.

A working page can still have broken section links

In the hypothetical link /services/#eligibility, /services/ identifies the page and #eligibility identifies a target within it.

The fragment is handled by the browser and is not sent in the HTTP request. Server-side path redirects therefore cannot distinguish /services/#eligibility from /services/#preparation.

Loading the page is not proof that the section link works. A successful HTTP response cannot establish that the target exists. Open the full link and inspect where it lands.

Capture known links before editing

Collect actual links from the page’s contents navigation, other site pages, customer email templates, downloadable guides and client-supplied materials. Do not reconstruct fragments from heading text.

Compare them with the current page’s target IDs. Ask the developer to inspect the rendered page if the editor does not expose them. Back up the content and relevant template configuration before rebuilding.

Each handoff entry needs the original full URL, discovery source, promised topic, approved target ID and location, implementation owner, content approver and status. Record browser observations separately for staging—a non-live test copy—and the live site.

Call this a known-link inventory, not exhaustive coverage of external bookmarks or distributed copies.

Approve an outcome for each changed section

Consider a hypothetical service page whose path remains /services/. Its redesign renames one heading, splits another section and retires a topic.

Renamed heading: retain the meaningful ID

The old link is /services/#eligibility. The heading becomes “Who this service is for,” but the eligibility information remains.

Keep eligibility as the target ID; it need not match the heading text. The content lead approves the guidance, and the editor preserves the ID. The old link must reveal the heading and instructions, unobscured by navigation.

Split section: preserve an orientation point

The preparation section becomes “Documents to bring” and “Before your appointment.” Attaching the old ID to only one half could hide part of what the original link promised.

Retain preparation on a visible introduction explaining both steps. Here is a hypothetical approved handoff entry. Its URLs are illustrative; implementation and tests are pending.

• Original URL: https://example.test/services/#preparation
• Discovery source: Appointment-confirmation email template and downloadable preparation guide.
• Promised topic: Everything a customer needs to prepare for an appointment.
• Approved target and location: preparation, on the visible introduction immediately before the two new sections.
• Onward targets: documents-to-bring and before-your-appointment, each on its corresponding section heading.
• Owners: Content lead approves the introduction; editor implements copy and anchors; developer checks rendered targets and layout.
• Expected landing: The introduction is visible, explains both steps and links to both sections.
• Status and evidence: Awaiting implementation and verification; staging URL https://staging.example.test/services/#preparation; desktop, mobile and original live-link results all pending.

Retired topic: explain rather than substitute

Assume the business has stopped offering on-site visits, with no equivalent replacement. Do not attach on-site-visits to an unrelated service simply to make the page scroll.

Retain it at a service-owner-approved retirement notice. Correct controlled links that still advertise availability. Updating a template or downloadable file does not repair copies already distributed.

If no useful notice can be approved, mark the journey unresolved. The service owner must decide whether it blocks launch or is an accepted exception with a named follow-up owner. An accepted exception is a known limitation—not a preserved section link.

Give editors and developers distinct implementation jobs

For a block that exposes an HTML anchor field, enter the identifier without the leading #, such as eligibility. Other blocks and builders may use different controls or offer none; confirm support.

Retain an existing ID if it still identifies the topic. A heading rename alone does not require a new one.

If a new ID is required, ask the developer to specify where both identifiers will land. A compatibility anchor preserves the old identifier at an additional, meaningful target; it is not a server redirect. The content owner must approve that location against the old link’s promise.

Every ID must be unique within the rendered page. Check reusable layouts and separate desktop/mobile copies for duplicates. Never put the same ID on both halves of a split section.

Record approved IDs in the content plan so later wording changes do not accidentally replace them.

Test the full link, not just the page

Create a staging equivalent for every recorded URL, preserving fragment spelling, capitalization and encoding. Document hostname or path substitutions. Open each full link in a fresh tab; testing only the contents navigation after loading is not enough.

Inspect these results on desktop and mobile:

• The intended heading or explanation remains visible after images, fonts and layout have settled.
• A sticky header does not cover the target or opening instructions.
• Tabs or accordions expose the instructions on direct arrival when the journey requires it.
• The landing answers the original link’s promise, and onward links reach their intended sections.

Do not assume a builder or accordion opens automatically. If direct arrival cannot reliably expose the instructions, revise the design or provide an approved visible orientation point.

A matching fragment in the address bar alone is not a pass. Record the browser, visible browser window size, date and observed result. Keep content approval separate from technical acceptance: an existing target can still contain the wrong information.

Close the handoff with evidence and decisions

Distinguish pending work, verified journeys and accepted limitations. Unresolved entries need a launch decision; staging evidence must not stand in for live results.

Working checklist

Tick each step as you go. Your choices are not saved or sent.

• Record the approved target ID and location, or unresolved outcome, for every known fragment.
• Attach desktop and mobile staging observations, including failures, to each handoff entry.
• Obtain content-owner approval and record whether each unresolved journey blocks launch or is an accepted limitation with a named follow-up owner.
• After launch, open the original full URLs, including links from customer materials where available, and record live results separately before marking journeys preserved.