Introduction

For those of us who have gone through Sitecore's training, we are all hyper aware of the fact that a broken link in Sitecore is bad. My SCD instructor Jim DeMarco discussed broken links as being the worst possible sin a content author or Sitecore developer could possibly commit. I'm exaggerating slightly, however there is a modicum of truth in that statement. One of Sitecore's many positive attributes is it manages very well the relationship between pages, items, and items-to-items in its Links Database. In fact, if an author or developer tries to create a broken link, Sitecore informs the user and asks them how they want to manage it. The fact that Sitecore allows for the creation of a broken link is somewhat less desirable though because a user can knowingly create a situation where a page or link will result in either a 404 or worse, a 500 error. The latter is a bad choice if search engine optimization (SEO) is a big deal for your site.

Most broken links are fairly simple to resolve. For example, a page or data item that has a link attribute on it that points to a non-existent page can easily be root caused using either the broken links report or even simply highlighting the broken links icon in the left hand gutter within Content Editor. Both will inform the user which field on the content item contains the broken link. The harder ones to resolve are ones that occur in the Layout or Final Layout fields, the fields that store the XML representation of your page's Presentation. For these situations, the former approach is useless. Both the report and the gutter simply show "Final Renderings" or "Renderings" with no explanation. There are, however, two additional approaches one can take in these cases.

Broken Link in a Datasource

In this particular scenario, a rendering on the page item is referencing a data source that no longer exists or is invalid. Note that when Sitecore reveals the fact that a broken links exists in a layout field, it doesn't tell you which Version of the item has the broken link. To discover this fact, I highly recommend you download Sitecore Powershell Extensions and run their broken links report. It will allow for showing only the latest version or all versions and you can quickly determine which version has the broken link. Following that exercise, you can also use the Navigate->Links drop down on the ribbon in content editor to see which item ID is invalid on the particular version of the page item. Lastly, you can open Presentation Layout Details on that item version and use the Edit option on the Shared or Final Renderings tab to see which rendering has an invalid data source. It will be visibly apparent.

Broken Link in Personalization

These are by far the most difficult to diagnose. If, for example, a personalization condition is applied on a rendering and the rule is later removed, none of the above can be used to determine which rule is the culprit. What I've found to be especially useful in these cases is to run the "Remove Broken Links" utility. This utility will not actually fix the broken links as its name implies but it will provide useful information in the Sitecore logs. In fact, you can then trace directly to the rendering and the exact personalization rule in the underlying XML representation. Once you've discovered which one it is, it's a simple effort to edit the XML directly and remove the broken link to the no-longer-available rule. Find me on Sitecore Slack (@sitecoretimmy) if you have any questions on these approaches and I'll be more than happy to help out.