Press release link maintenance starts after the announcement goes live. A release can be accurate on publication day and still become unreliable when a product page moves, a campaign redirect expires or a PDF is replaced without a route from the old URL. The fix is not to freeze every link. It is to give each destination an owner, choose redirects deliberately and test the public path that readers actually receive.

Sources checked: 27 October 2026. Redirect behaviour depends on the site, the destination and the request method. The checklist below is for ordinary public announcement links, not payment, authentication or other sensitive flows.

List every outbound and internal URL in the approved release. For each one, record:

  • the link text readers see;
  • the approved destination;
  • whether the destination is permanent or campaign-specific;
  • the person or team that owns that page;
  • the expected HTTP result;
  • any campaign parameters;
  • the date on which a temporary route may be retired.

This register is more useful than a screenshot of the final draft. It lets the publishing team compare outlet variants, the canonical release and downloadable files without guessing which link was intentional.

Separate content links from measurement parameters. The product page is the content destination. A UTM string is a measurement layer attached to it. If analytics parameters change, the underlying page should not need a new editorial approval unless the destination or promise also changed. Our press release UTM tracking guide explains how to keep that layer consistent.

Use descriptive link text

“Click here” tells a reviewer almost nothing and gives a screen-reader user little help when links are listed outside the paragraph. W3C guidance for WCAG 2.4.4 says the purpose of a link should be clear from its text or from the programmatically associated context.

Write the destination into the label:

  • “Read the API migration guide”
  • “See the Series B filing”
  • “Download the approved media kit”
  • “Review availability by country”

That wording also makes a broken-link report easier to understand. A test can say “API migration guide returns 404” rather than “third link in paragraph six failed”.

Do not hide a destination change behind the same label. If “Read the pricing page” begins sending readers to a generic homepage, the link technically opens but the release no longer supports the claim beside it.

Choose the redirect by intent

The HTTP standard distinguishes redirects that are temporary from those that are permanent. For ordinary public pages:

Situation Usual response What it communicates
A page has moved for good 301 or 308 Future references should use the new URL
A destination is temporarily unavailable 302 or 307 Keep the original URL as the continuing address
A URL is still the correct page 200 Serve the promised content directly
Content is intentionally gone 404 or 410, with an explanation where useful The old destination is no longer available

Google Search treats permanent redirects as a signal that the target should become canonical. It treats temporary redirects differently: the source may remain the search result. That is why an expired campaign link should not automatically become a permanent redirect to the homepage.

Use a server-side redirect when the platform allows it. Google recommends server-side redirects as the clearest option and warns that JavaScript redirects depend on rendering. Keep chains short. If URL A moves to B and B later moves to C, update the first rule so A points directly to C.

For POST requests and application flows, status codes can change request behaviour. RFC 9110 notes that 307 and 308 preserve the method, while older 301 and 302 handling can change a POST to a GET. An announcement editor should not redesign those flows. Send any form, payment or sign-in redirect to the product and security owners.

Keep the canonical release stable

The release URL is a public record. Do not change its slug just to match a revised headline. If the CMS or domain architecture forces a move:

  1. create the new URL;
  2. place a permanent redirect on the old one;
  3. update the canonical tag and sitemap entry;
  4. change internal links under your control;
  5. test the old URL, the redirect and the final page;
  6. keep the correction or revision note on the public release when the facts changed.

Syndicated copies may continue to point to the old address for years. A working redirect protects those references. It does not rewrite the copy on partner outlets, so material corrections still need the press release corrections workflow.

A campaign landing page needs an exit plan. Before distribution, decide what should happen after the offer, event or registration window closes.

A useful closed page can:

  • state that the window has ended;
  • preserve the original dates;
  • link to the current product or newsroom page;
  • keep a contact or support route that is still monitored.

A silent redirect to a different offer is risky. It changes the meaning of old coverage and can make a dated claim look current. If a campaign page must redirect, record the date, reason and target in the link register.

Shorteners need the same treatment. Record the final destination and the account that controls the short link. Do not put a third-party shortener into a permanent source document unless the owner has accepted the dependency.

Test more than the first response

A green 200 result is not enough. The destination may render an error message, require an unexpected login or display the wrong market.

For every public link, check:

  1. Status: does the request end in the expected response?
  2. Final URL: did it land where the register says it should?
  3. Content: does the page still support the surrounding claim?
  4. Market and language: is the intended reader seeing the right version?
  5. Mobile: can the destination be used at a narrow width?
  6. Accessibility: is the link text meaningful and is the destination identifiable?
  7. Files: do PDFs and images open fully, with the approved version?
  8. Tracking: are parameters present without exposing private data?

Test the public release, not only the CMS preview. Then test at least one distributed copy, because a wire or outlet may alter parameters, encode characters differently or remove a link.

Set a practical checking cadence

Run the full check at four points:

  • before the canonical release is approved;
  • immediately after the first public page appears;
  • when distribution is complete;
  • at the end of any campaign window.

For longer-lived releases, repeat checks when the linked product, documentation or legal page changes. A daily crawler is useful only if someone owns the alerts. Without an owner and a response rule, frequent scans produce a backlog rather than reliability.

Classify failures so the right team can act:

  • editorial: wrong label, wrong destination or unsupported claim;
  • web: broken route, redirect chain or rendering failure;
  • campaign: expired landing page or tracking configuration;
  • third party: destination outside your control;
  • expected retirement: approved removal with a documented replacement or explanation.

Final publication check

Before distribution, confirm:

  • every link appears in the register;
  • link text says what the reader will get;
  • permanent pages return 200;
  • moved pages use the intended redirect;
  • redirect chains are direct and finite;
  • campaign expiry behaviour is approved;
  • canonical, sitemap and internal links agree;
  • PDF and HTML versions use the same destinations;
  • one owner is named for every future check;
  • the public release and at least one distributed copy were opened.

A release is not finished when its links work once. It is finished when the team knows which links must keep working, who will notice a failure and what should happen when a destination changes.