| |
Popular websites have to change, otherwise they become boring and
will steadily lose their repeat visitors. But managing those changes thoughtfully is of
the utmost importance. If you own and/or manage a website, it is important to appreciate
that, if you delete any of your hosted online files, or even move or rename them, the inevitable
consequence is that you are going to cause broken links all over the internet in search engines,
in web directories, in forums, in people's bookmarks, on other web pages which have linked back
to you, and even in computer magazines which may have mentioned pages within your site.
We are talking here about broken external links, not internal links. External links
are the ones you don't even know exist, but are all out there linking back to various pages
in your site and, therefore, bringing traffic to your site. Broken internal links
within a site can have the same undesirable effect. But they are easily fixed.
In fact, most WYSIWYG web design tools will alert you if you make changes which will break a
local (internal) link - and can repair the (local) damage automatically. But therein
lies a major danger. Fixing a broken internal link during off-line editing of a site is
so simple and automatic that it often blinds even the best of webmasters to the fact that, when
they subsequently upload the 'repaired' page(s), that will, immediately, and unwittingly,
result in an unknown number of external links back to the previous online-page(s)
being broken. It is all too easy for anybody to forget, or deliberately disregard, all
those backlinks because one never knows where they are, nor how many there are. But the
danger is still there that, each time you move, delete or rename a page or folder, you could
be breaking dozens of such links, possible hundreds, even thousands - all depending on
how popular your own website is and how useful the page(s) with the now-defunct
address had been.
Broken external backlinks are, of course, bad news for surfers - but are even worse news
for you, whether you are the web designer, webmaster, website owner or paying client, as the
site will be losing traffic which was trying to come to it. In most cases, that traffic,
unbeknown to you, will either be re-routed by settings in the viewer's browser, often applied
by invisible adware infecting the user's machine, to somebody else's totally unrelated bogus
page or, just as bad, be blocked by a useless "Error 404 : Page cannot be found" message.
It is not uncommon to find topflight web designers working on leading commercial websites failing
to appreciate the disservice they might be doing to their client's would-be visitors whenever
they make even minor changes to the internal structure of a website.
Search engines and web directories can be profoundly inefficient and unsatisfactory in the differing
ways with which they deal with any broken links which web designers or webmasters may have inadvertently
caused them. Some engines may continue to use an index with obsolete links pointing to
non-existent pages for months on end. Some will never bother to revise their
index with any alternative or updated pages you may have uploaded or submitted. While
others will just drop you from their index altogether. All these are, of course, totally
undesirable scenarios for the site owner and so need to be avoided by the site maintainer if
they are at all conscientious in their work.
As for viewers who have made bookmarks to any now-defunct pages, when they try to come back
to the page in the future, they will just see a junk-menu page or an error message. In
either event, they will delete the dead bookmark and that could be the last your site will ever
see of them.
If you believe you might have created any of these bad situations by moving, deleting or renaming
any folders or pages on your own website(s), or you would simply like to know how
to avoid it happening to you in the future, here is a simple method which will ensure broken
external backlinks to your site, wherever on the internet they might be, will be diverted automatically
or manually to valid pages of your own choosing. All it involves, basically, is putting
one small file online, in the same location and with the same name as each page which is
due to be deleted, moved or renamed. We call it our 'fixlinks' page. It will enable followers
of any of your broken external links to be redirected to a suitable new page elsewhere within your site. That could be a replacement
page, if there is one or, if not, simply to your Home page which, of course, is far better than losing them period.
META Refresh Tag issues

Our 'fixlinks' page can be used with or without a 'META
Refresh' tag in the page's source code. This tag is not favoured by some webmasters due
to fears about Back-button loops. Or concern over some search engines possibly ignoring pages using the tag
- or even banning the site altogether. Exactly which search engines are supposed to do that nobody
has ever made clear so it might just be an urban i-myth. In our experience, we can, at least,
safely say that neither of the two search engines which really matter, viz. Google and bing.com,
will ban a site as long as it is not using the Refresh tag improperly or deviously. That
said, when you copy the code from Fig 1, you can, if you prefer, simply delete the META
Refresh tag in order to err on the side of caution, which is what we tend to do ourselves.
The code will still serve its intended purpose of preventing the breaking of external backlinks to
your site. The difference being that it will do so as a plain, visible, interactive
redirection page with a link to be clicked, instead of being an invisible, automatic redirection
page. If you like the sound of auto-redirection, but don't want to use the META Refresh tag, it can
be done via a small JavaScript in the page, with the 'through link' being placed in a NOFRAMES
tag. If that would interest you, see tip 4 in the RH column.
To create the redirection page
|
|
| Take the following steps to use the code from Fig 1 to create
a master 'fixlinks' page which can then be deployed as often as required to prevent broken external
links back to your online pages. |
|
|
| 1. |
Use your mouse to highlight all the HTML code in Fig 1 > press Ctrl+C to copy it to your clipboard > go to your computer's Accessories menu and open Notepad > press Ctrl+V
to paste the code into Notepad > click File > Save As > at the 'Save in' field, browse to and open the off-line root
folder where your website's Home page is stored > at 'File name', type in fixlinks.htm > at 'Save as type', choose 'All Files' > Save. |
|
|
| 2. |
After you have saved the code from Fig 1 as "fixlinks.htm", look through the code you pasted into Notepad for a long URL which ends with the letters supa. This
is part of the word supanet which has been split over two lines so the full URL would fit in the available space. It needs to be joined together by removing the invisible 'line break'. To do
that, put your mouse cursor after the letter 'a' in supa and press the Del key. This will join the split URL together so that, as far as Notepad is now
concerned, the line will have no line break in it. |
|
|
| |
The file "fixlinks.htm" is a master page that is NOT intended to be uploaded.
You now make a COPY of it and rename the copy with the exact name of your defunct page.
If you have made, or are making, more than one page defunct, make further copies of the master,
naming each one after one of the other defunct pages. You then move each such copy into
the same off-line folder that once held, or still holds, the corresponding (renamed) defunct page.
If you have renamed or deleted an actual folder that a defunct page was in, recreate that folder too,
giving it exactly the same name and relative location that it originally had. After you
have moved each renamed copy of fixlinks.htm into its relevant folder, open any one of those moved pages, in Notepad, and look for the two occurrences of the address "http://www.xxxx.com". Change the "www.xxxx.com" bit of both to the actual address of the valid page to which you
would like any broken links pointing to the defunct page to be redirected e.g. http://www.sitename.com / foldername / pagename.htm. Use the same address to replace both instances of www.xxxx.com. Use a full
absolute address (i.e. one beginning with http://...), not a shortened relative address. If
you no longer have a page with similar content to the... continued in
RH col. |
|
|
| Fig 1 The screengrab below of Notepad displays the HTML code needed under
step 1 in the LH col. The code is ready to be copied and pasted into the window of
Notepad on your computer, then saved as an htm file. Copying the code from here will save
having to type it out. |
| Item 2 continued from LH column |
|
| |
defunct page, use the address of your Home page, in which case "http://www.xxxx.com" would become something like "http://www.sitename.com / index.htm". The link appears
twice because one is for the refresh action and the other is to let search engine spiders pass through so they can update
their indexes. Leave the TITLE tag in all the copied pages the same as shown in Fig 1, i.e. "Fix broken links (non-indexable page)". This will serve as a simple means of
locating all such pages, in the future, en bloc, should you need to, by the simple means of searching your computer for files containing the word 'non-indexable' or just 'indexable'. The
said title will also serve as a simple reminder of what the pages are for if, at anytime in the future, you happen to stumble across them when looking through your site's off-line
folders or its online FTP folders. |
|
|
| 3. |
When you are happy that all the copies you have made of fixlinks.htm have been
correctly renamed, deployed, and the two redirection links have been repathed in each such
copy, upload the pages. You can now forget all about them while they quietly do their
thing. However, you have to remember, the next time you are thinking of moving, renaming or deleting
any of your web-folders or web-pages, you will need to follow this same procedure again, each time,
if you want to avoid causing any more broken
external backlinks. |
 |
 |
 |
 |
| |
Tips |
|
 |
 |
 |
 |
| |
1 |
robots.txt file
Assuming, after carrying out the procedures on this page, there are no remnant broken links
on your website to any defunct folders or pages in your site, there will, consequently, be no
links to point to the renamed copies of fixlinks.htm created with the procedure left.
This ensures spiders will not find and index these zero-content pages. They are there
purely to redirect any existing broken links on the internet, nothing else. However, a
comprehensive noindex Meta tag is included in the code in Fig 1 above to discourage indexing -
just in case there are any stray links still hiding in your online pages. If you want
to be doubly sure of preventing indexing of these zero-content pages, disallow them in a robots.txt
file and upload that file as well. You can find full instructions for creating and using
such a file via an internet search for the term "robots.txt". |
|
 |
 |
 |
 |
| |
2 |
Meta Refresh disabled
The code in Fig 1 provides for instantaneous redirection to an alternative page of your
choosing - but this will not work in the case of a small minority of your visitors who
might have disabled META REFRESH in their browser (under 'Advanced' options as of IE 6).
They would only see the redirection page but, to avoid them seeing it as a blank white screen,
an ordinary blue link is included in our code for them to click on. This manual link will
take them to the same page as all the people who have not disabled the REFRESH option. |
|
 |
 |
 |
 |
| |
3 |
.htaccess file
If your web pages are hosted on an Apache server, as many are, there is, supposedly, an alternative
way to the one given on this page for redirecting broken links. It is achieved by placing
a text file called '.htaccess' (note the preceding dot) in your online root folder. This
file can be defined to automatically cause broken links to be redirected to alternative pages
or to a customised 404 error-message page. To check if your pages are on Apache, visit
Server Types and
type your own URL in the box. You can find full instructions for creating and using this
special file via an internet search for the term "htaccess".
However, htaccess files are prohibited by a good many hosts and ISPs, irrespective of the server
type, so do not be surprised if this method proves to be not available to you if you try it.
You need have no such concerns about the full method set out left, which will work irrespective of
server type or host restrictions. |
|
 |
 |
 |
 |
| |
4 |
Redirection by JavaScript
Instead of using a META Refresh tag to achieve automatic redirection of visitors from a defunct
page to a valid page, this can be done via a JavaScript. To do that would mean arranging
the fixlinks.htm page to act as the content part of a (non-evident) frameset page. A short
and simple JavaScript is available to perform the redirection. Search engine spiders would
pass the frameset by means of a through link hidden in the NOFRAMES message. To find a
suitable script, use a search engine to look up +javascript +redirect +noframes. When doing
any random searching of this kind,
you would be well advised to disable JavaScript and ActiveX temporarily, in your browser or your firewall,
as a precaution in case the search engine's links send you to a booby-trapped page. |
|
 |
 |
 |
 |
| |
5 |
<CSEIGNORE> Tag
In case you are one of the many people who user CSE HTML Validator for verifying the source code
in your web-pages, the Refresh tag (in Fig 1) has been pre-enclosed in CSE's proprietary 'ignore'
tags. That is because the presence of a META Refresh tag in a page would normally cause
CSE to flag up one green error. The CSEIGNORE tag prevents that. Hence, scanning a fixlinks.htm
file with CSE Lite, Pro, or the online CSE scanner, will duly report "Congratulations... 0 errors, 0
warnings, 0 messages". |
|
 |
 |
 |
 |
| |
6 |
DOCTYPE Tag
Do not worry if the top tag in the 'fixlinks' code differs from the DOCTYPE definition used
on your other existing pages. Browsers read the DOCTYPE separately for each page they
are asked to render, so no conflict will occur. |
|
 |
 |
 |
 |
|
|
|