Lots of our clients have the issue of broken links in ancient PDFs and changing/deleting content is not always a permitted or desirable option for them. 

However, several of our users are updating the PDFs by removing the hyperlink and leaving the URL as text - some will add a note saying the page no longer exists. 

This maintains the integrity of the original document but ensures that people don't click on a useless link that no longer works, which is an irritation we should seek to avoid.

Having the original source of PDFs can also be a problem.  However this has been resolved in the latest version of Adobe Acrobat (version 9) with the addition of the Export feature allowing you to export an existing PDF to, say, Word (retaining all formatting) so that you can edit the document and then convert it back to a PDF.  Take a look at a demo here http://www.adobe.com/designcenter/video_workshop/?id=vid0333&trackingid=EWLWW

This feature could also be used if tagging an old PDF for accessibility has proved problematical in the past.

I believe this approach would address concerns of removing errors from a Sitemorse audit without compromising the integrity of the original document.

If, however, making any sort of change to the actual documents is impossible / impractical / banned then an alternative may be to consider creating an area (perhaps as even a sub site / subdomain etc) that we don't review, you could then put all the 'old' pdf's that you can not change or alter in this area, make it clear that that area has old documents that may offer limited capability.

It's not Sitemorse's intention to encourage people to take inappropriate actions (to delete an old PDF that should remain on the website) in order to maintain their positions in the Surveys we run.  The audits we run and the information they contain are an invaluable source of information for organisations to maintain the highest possible level of site quality and user experience possible.

This is one objection that our sales people get quite a lot.  Often because people in this position are starting to look at how they'll test the new site before launching and enquire about our services.

Website managers often hold the view that until the new site is heavily populated with content that it isn't worth spending time testing as there's nothing to test.  So, yes, they are interested in Sitemorse but "not just yet". 

However, lets look at the rationale behind the presumption that taking Sitemorse when you've just embarked on a major redesign of your site is a waste of time.

Will ABSOLUTELY NONE of the content from the old site move to the new site ?

Unlikely.  So you can be testing the current content right now to make sure it's OK.  That way you don't taint the new site with old errors.

PDFs are a great case in point.  I would suspect that most of your PDFs will move to the new site.  Make sure that they are all accessible and that any links and mailto: links work.

How about Templates and Style sheets ?

They may change but who wrote the old ones and who is writing the new ones ?

If it's the same people or the old ones are being updated rather than scrapped you could bring poor quality practices into the new site from the old.  Test them now and clean them up.  That way your developers will familiarise themselves with best practice BEFORE coding the new site.  It's often easier to learn by your (or others') mistakes than to learn from a text book.

What about external links and feeds ?

It's pretty likely that you'll retain a high proportion of your existing links and feeds.  Do you know how well they all work right now ?  How many links fail on your site currently ?  How many have permanent redirects set up ?  How may mailto: links go to non-existent email addresses ?  Now is a good time to find out before you port them to the new site.  Sitemorse will also test the first page of a linked site, running all of its test on that page.  If it fails miserably you might choose not to link to it anymore as it would taint your new site's image.

How accessible is your current site ?

If you find out what you didn't do too well on the old site you can make sure you don't repeat the same mistakes on the new site. 

Hindsight is OK but foresight is much better.

And is your code standards compliant.

As this is the section that most organisations get their lowest score it's reasonable to assume that the most likely case is that it isn't.  Internet Explorer has been very tolerant of non-compliant code (see my blog posts http://blog.sitemorse.com/2008/06/firefox-3-hits-8-million-downl.html and http://blog.sitemorse.com/2008/06/ie8-standards-compliance-issue.html) which has allowed coders to write code that they assume is fine because it seems to work OK.  My blog posts explore this topic in more detail but essentially that fact is becoming less true as Opera, Firefox, Safari and now IE8 become much less tolerant.  Check out what you do wrong in your old site now so you don't make the same errors in the new site. 

It's MUCH cheaper to engineer out errors while you're coding than to correct them later when you're testing or they fail on the Live site.

I believe the answer to the question of when should you start testing your new site is BEFORE you even start to develop it. 

We have seen many new site launches spoiled by poor content transferred from the old site.

Just a quick note on PDFs.  We had several recent questions about PDFs and what checks we perform and how the results affect the scores.

We perform 2 sets of tests.

Link checks
Accessibility checks

For the links we take a look at and hyperlinks to web pages or mailto: links.  We perform the same level of testing as we do when checking web pages.  So we check a link and make sure the web page is available.  If it works fine, if not it is reported as an error.  We attempt to send an email to all mailto: links we find and if the receiving email server would accept the email that's OK but if the email server rejects our attempt then this is reported as an error.  Usually this is because the email address no longer exists.  We don't actually send an email, as soon as the email server says it will accept the email we cut off.

Accessibility checking is limited to checking that the PDFs have been tagged.  PDF Tags create a text-only representation of the PDF document, which is hidden inside the PDF file and presented to screen readers instead of the original document.  This feature has been available in Adobe Acrobat since version 6.  But I understand that version 7 onwards is a much better implementation of the feature.  We check that the PDF has been tagged.  If it has that's OK if not we flag it as an error.

In terms of how these tests affect the scores:-

The link checks WILL affect the score.
The accessibility tag checks do NOT currently affect the score, but we are reviewing this.

If you'd like more information about how we handle PDFs please look at our Knowledge Base entries at http://www.sitemorse.com/kb.html?query=pdf