/
URL Redirects Process and Procedures

URL Redirects Process and Procedures

Overview

Redirecting URLs is the practice of resolving an existing URL to a different one, ensuring visitors and search engines get to the page they intended after it has been relocated to a new location.

Redirects support search engine optimization by informing search engines that content has moved. Therefore, search engines only need the redirect until they understand where the content resides. Our processes and procedures align with Google’s recommendation to keep them for one year.

Historically, redirects have been created as part of projects to ease a transition to a new system. As any transition is a temporary thing, we want to ease the ongoing maintenance burden of redirects by outlining the criteria that signal the end of that transition.

Rationale

Redirects require effort and knowledge management to maintain. Minimizing the number of redirects enables our systems administrators to allocate more time to projects, enhancements, and maintenance.

Redirects are not intended to support users’ bookmarks. Stakeholders must communicate changes to application URLs to end users within a predictable time frame.

Process

Redirects will expire one year after being implemented. They will be reviewed at expiration to determine whether they should be retained. To retain a redirect, Stakeholders must present reasonable evidence to the appropriate Product Manager to ensure it is renewed for one more year. The Product Manager will consult with the Systems Administration team and (if necessary) leadership to determine whether the redirect will remain. There is no limit to the number of times a redirect can be renewed. After review, the stakeholder will be informed of the outcome (renewed or expired). A redirect will be removed one month after it expires, allowing stakeholders to communicate with their users.

To facilitate this process, we will keep a list of redirects, and redirects will be included in Operational Level Agreements for an application.

Exceptions

This process does not apply to redirecting HTTP traffic to HTTPS, as required by OIT Security, to redirects that support specific application functionality, or to redirect routes that exist internally within applications themselves. We will keep a list of exceptions which will not require annual review. Collectively, these sorts of redirects are exempted from review because they have no alternative implementation and are required by the application.

Contact

Questions about this process and associated procedures should be directed to the head of Software Development.

Guidelines for Keeping Redirects

Instead of seeking universal answers, we need to understand the nature of each individual redirect and how it is used. Here are some examples of why we would keep a redirect:

  • The new URL was implemented less than 6 months ago.

  • The old URL received at least 100 visitors in the last month, as shown on a relevant analytics tracker.

  • The URL has not yet been set up on OIT’s redirect server, but a date for this is planned in the future.

  • OIT has denied the request to set up a link on their redirect server (Not sufficient alone, must come with other reasons).

  • There are links to the old URL on a university website that cannot be edited directly by the owners, and a planned implementation date has been set for making that change.

Examples

Redirects that do not need exemptions:

Redirects that do require exemptions: