Before I forget again, I’d like to boast that Woking have leapt from position 128 to 51 in the SiteMorse rankings for December. The monthly “league table” of Local Government sites currently ranks 460 authorities against each other on a range of criteria.
Although we’ve just moved over to a faster server and a better metadata system, I doubt that either of those have made the difference this month. The new server is responsible for the average page generation time going from 0.9 seconds to around 0.6 seconds. A third off is a bargain by anyone’s standards, but we’re still failing the download speed tests for both modem and ADSL connections. When I’m finally able to do it, the long-awaited CSS makeover of the site should cure that.
No, I strongly suspect that what made the difference was a clampdown on broken links. There’s not a vast amount that a (fried not baked) CMS can do about broken external links, so Woking have invested in a link-checking service to help us keep track of those.
It’s in the realm of internal links that the CMS can help. When creating a page, publishers can link to other resources using a dialog that encourages them to enter the link destination one way for an external link, another for links within the site, plus another for email addresses and — in a novel twist — a fourth for links to pages that haven’t actually been created yet. By recording the ID of internal pages that are being linked to rather than their published URL, the CMS can make sure that links from one resource to another are kept up-to-date even if the resource being linked to is moved from one part of the site to another. It also allows the system to construct the link according to the browsing circumstances, so if you’re in one version of the site, you stay there rather than being shunted to another version.
Given that, there remain two circumstances in which an internal link could become broken:
The link is to a resource which is subsequently deleted from the site altogether. Even if the CMS emails notification to all publishers who have resources linking to the newly-deleted resource, there’s still inevitably a period of time when the page has a link leading nowhere.
A resource in test links to another resource in test. The first resource is then made live before the second one. A page in test — that hasn’t been published to the live site at all yet — is invisible to the live site, and will consequently 404.
We came up with the following technique to help deal with this:
When the CMS is constructing an internal link to be viewed on the site, it’s of course able to note whether the link is effectively broken, and can consequently adapt the link and take further action.
hrefattribute isn’t mandatory on the
atag, so the CMS doesn’t add it, but does add a
titleattribute noting that a link was there, but it’s been removed.
The CMS notes the time, the resource containing the link, and the link ID in a database. If the last time a matching link was added was more than 24 hours ago, it sends a broken link notification email to the publisher responsible for the resource being viewed. One nagging email a day is quite enough, thank-you.
If the page is being viewed from within the Council’s network, the background-colour of the link is styled a bright yellow, which helps bewildered publishers find the part of the page that’s going wrong.
Consequently, from the perspective of the casual visitor to the site, there are no broken internal links any more — although there might be phrases that seem out-of-context without a link adorning them. If publishers are careful not to over-use click here, even that shouldn’t be too much of an issue.