Redirects and Broken Links
When a redesign launches, it’s not unusual for the site structure to have changed significantly, which creates a significant number of broken links. Before site launches, we take several steps to catch broken link errors to the best of our ability.
Broken Links
NOTE: To request a Broken Link Report or Full Link Report, file a help ticket with IS&T.
Broken Link Report vs Full Link Report
There are two types of reports you may need to be certain your site is full of successful links.
Broken Link Report
A Broken Link Report is a scan of all links on the new site – inline links, menu items, buttons, etc. This allows the client to be sure that all links on the new site successfully link somewhere else before you launch.
Full Link Report
The Full Link Report is a report that lists all URLs on the CURRENT site against all URLs on the NEW site. This allows the client to see where all current links will point once the new site is live. If pages/posts have been removed, renamed, or reorganized in the navigation structure, you will need to create redirects for the links on the current site so that they point to the new location.
Example 1
On the CURRENT site the URL might be http://www.bu.edu/academics/eng/undergraduate-policies/academic-progress-and-graduation/
However, on the NEW site, the URL is https://www.bu.edu/academics/eng/policies/undergraduate-policies/academic-progress-and-graduation/
Using the old link without a redirect, WordPress may send you to http://www.bu.edu/academics/sargent/undergraduate-policies/academic-progress-and-graduation/
The reason why you get Sargent’s version instead of ENG’s version is because WordPress is trying its hardest to NOT serve a 404 error. It thinks, “I’m looking for academic-progress-and-graduation—oh, Sargent has one, I’d rather give that than a 404.”
With a redirect we can safely point the old page to the new page, which guarantees all search engine results, bookmarked pages, and links from other sites get updated and all point to the same new location.
Example 2
http://www.bu.edu/marcom/profile/tom-coolguy links to a profile for Tom Coolguy, the MarCom FunTime Manager, on the current site. However, on the new site Tom Coolguy’s profile has been removed because he’s moved on to other cool guy things.
Using the old URL without a redirect, WordPress may send you to http://www.bu.edu/marcom/profile/tom-otherdude because once again WordPress thinks it is smart enough to solve the problem and doesn’t want to look bad sending you a 404. But Tom Otherdude isn’t the new MarCom FunTime Manager, he’s just another Tom.
With a redirect pointing to http://www.bu.edu/marcom/profile/ we could be sure that the user is getting sent to the Profile Archive page and can find the new MarcCom FunTime Manager on their own.
Team and Client Broken Link and Redirection Responsibilities
- IS&T is responsible for generating a Broken Link Report 3-5 days prior to launch. The Broken Link Report looks at all links in the site content, “pretends” to click them, and lets you know if they are broken or not. This report is run at the time your launch request is submitted and processed; please ensure you send your request several days ahead to allow time for the team and client to fix broken links.
- The lead designer and developer are responsible for reviewing the Broken Link Report for large, overarching patterns of links that are broken, fixing them using site redirects, marking the items as complete or deleting them in the report, and passing the report on to the project manager to hand off to the producer, client, or both.
- The team members in charge of Information Architecture and content import are responsible for identifying section names that have changed and pages that have moved sections to the best of their ability, and notifying the developer of these changes so redirects can be created. A Broken Link Report will only catch broken links that are present in site content at the time the report is run. This step is required to identify possible broken links that are not linked to in site content and is not optional.
- Get in front of this tedious task early – track the former slug name when you reorganize information architecture, and set up redirects during the content import.
- The producer is responsible for repairing any broken links that were the result of issues in a GatherContent import. If you encounter a large or overarching issue with an easy-to-see pattern (for example, all links in a certain widget are wrong), loop in a developer – they may be able to help with a script and save hours of tedious work.
- The client is responsible for repairing broken links in content that are not the result of a theme, IA, or content import change.
- The developer is responsible for creating redirects, and the designer is responsible for verifying they work correctly.
- The client is responsible for final verification that pages were properly redirected. It is normal and expected for several broken links to be discovered on launch as many clients have certain items bookmarked or in their browser history for quick access. It is very difficult to identify every single case before launch, and they are easy to find and fix as long as we’re all on the lookout for them.
- The client is responsible for alerting the team to any missing redirects or broken links after launch so that we can fix them.
How to Get Full Link Report and Filtering Excel
To get a full list of all the links on a site, request a Full Link Report with IS&T and include the name of the site you want to pull the link report from.
- In the Data tab, select the area you want to filter and choose Filter
A. Select the arrow on the top right of the selected area
B. Enter the information you want to filter by
If you are working on a staging site, for example, http://www-staging.bu.edu/neidl/, and want to know all the links that are linking to the current live site, http://www.bu.edu/neidl/, you may want to filter by the path to the current site: www.bu.edu/neidl/.
C. Include or exclude data by checking or unchecking the boxes of the date filtered
D. Save your filtered spreadsheet as a new spreadsheet with these filters
Redirects
As of 2023, there are two methods for redirects. See this Slack conversation for some more details.
- “Network” Redirects. These are handled by IS&T and added to the Webrouter, in GitHhub: https://github.com/bu-ist/webrouter-prod
- It’s important to note that there are two types of redirects that can be entered. It is important to understand these and specify which we need in a ticket OR consult with IS&T to help determine which is correct for your needs:
- redirect appends the incoming URL to the redirect URL. For example, /oldsite/some-page -> /newsite/some-page/
- redirect_asis takes all variations of the incoming URL and redirects them to a single new URL
- Network redirects are used for “marketing URLs,” to redirect an entire site when it is shut down, such as merging a site into another site.
- It’s important to note that there are two types of redirects that can be entered. It is important to understand these and specify which we need in a ticket OR consult with IS&T to help determine which is correct for your needs:
- Safe Redirect Manager in a site handles most other redirects and is used in conjunction with network redirects to further redirect pages and URLs
How to Redirect a Page or Section
Safe Redirect Manager is best for individual page redirects, or redirects of an entire section of a site. For example, “this page moved here” and “we renamed X section to Y but all the page titles underneath are still the same” are both examples of times when Safe Redirect Manager is the best choice.
How? Enable the Safe Redirect Plug-in and then visit Tools > Safe Redirect Manager. Follow the on-page directions carefully. If you’re having trouble setting up a redirect, contact a developer.
Example:
The list of all of the redirects on a single site:
Editing an individual redirect rule. Follow the on-page directions carefully:
How Safe Redirect Manager Handles the Order of Redirects
Safe Redirect Manager (SRM) uses the menu_order followed by the ID (post id) of the SRM posts to determine the order redirects should apply. All SRM posts when entered have a menu order of 0. There are times when you have page-specific redirects such as /somesite/some-page that redirects to /somenewsite/some-new-page as well as a “catch-all” redirect for /somesite/* that redirects to /somenewsite/. To have the page-specific redirect match first, you may need to adjust the menu order.
Note: Because the menu order by default is 0, you may find that posts with a lower post id (those created first and hence older) will be superseded by newer (higher post id) SRM posts. So if you enter your catch-all redirect before page-specific redirects that may function correctly. However, if the catch-all is added after and has a higher post id, you may find that it breaks the page-specific redirects. Confusing? Yeah…hence this note being added.
Controlling the Order
You can control the order redirects take effect with menu_order by changing the “order” field in the metabox when editing an SRM post. For a recent project, we set our catch-all redirects (/somesite/*) to have an order of 100 so they are matched AFTER the page-specific redirects in SRM that were left with a default menu_order of 0.
How to Redirect an Entire Website
BU Network Redirects are redirects that affect the entire site. These are good for redirecting entire sites, or large sections/patterns of a site. These are entered on a network-wide basis in the Webrouter in GitHub and are handled by IS&T. For example, if you are combining several sites together in your redesign, such as migrating a separate magazine site’s content into the parent school site, you may need a network redirect to point visitors to the old magazine site to the new school site’s magazine section.
How? If you suspect you’ll need this kind of redirect, talk with your developer, project manager, or account manager and they’ll get the conversation started.
Important Information for Redesigns (Not Brand-New Sites)
All site redesigns will need to request a recrawl using the Google Search Console. If you do not have access, contact your developer. If your developer doesn’t have access, Ashley has access as a backup.
Note: BU Source URLs are now deprecated. Please do not use them unless the site already is using them.
Important Information for Deprecating Sites
In some cases, a project may combine one or more sites or abandon an older site, and require the deprecation of an older site and URL.
In this case, there are two parts that need to be addressed: a bulk redirect of the old site that will preserve URLs (this is important when speaking with IS&T), and then redirects being entered into Safe Redirect Manager (SRM). The first part will involve someone from IS&T and should be planned in advance through the creation of a ServiceNow ticket. PLEASE NOTE that the bulk redirect should be put in place after the new site launches, not before. The new site should launch and have a little time to ensure that things are working before this is attempted. The redirects can be added to SRM at any point throughout the adding of content, prior to site launch, and even after launch.