Why Sites Fail

This page is designed to help Users understand why a site might FAIL the checker. Contrary to what members like to think, it's not always the fault of the ring checker. The checker has an accuracy rating of just under 100%. Many errors that are blamed on the checker are really because the page host times out during the check. But more often than that they are due to member errors, whether accidental or due to a lack of understanding of the checker or the rules of code placement. There are also other things that could be done differently to achieve a PASS test. Then, there are the extremely small number of sites that just are never going to PASS.
If you currently are dealing with a site that isn't PASSing the checker, instead of using this page, visit the Troubleshooting FAILures page. This page is a comprehensive list, but the troubleshooting page is designed to walk you through the various possibilities and rule out some in order to pinpoint the actual problem. Once you've targeted the problem, refer here for details and remedies.

For convenience, each is color-coded: problems in red and suggested fixes in blue.
  1. Code not present on registered URL or properly linked WebRing page
    The basic rule of WebRing is that the assigned code must be on the same URL which serves as the entry page to your site from the ring. Either the code is not there or it's the wrong code.
    Fixes: Install code, move code; rename ring page file; edit URL & copy new code

  2. Registered URL is a redirect instead of the assigned URL for the site
    Many redirect URLs use JavaScript, which interferes with the checker, which is in search of WebRing JavaScript. Save shorter redirects for search engines and sharing with others. Your own domain assigned to a site with it's OWN address may also fall into this category.
    Use assigned URL for site and avoid redirects of any kind

  3. Code is placed on a page that also contains a meta redirect to another page
    This is similar to #2, except that the checker is being directed away from the code. (It's ok to put the code on the page to which the visitor is redirected) Remove meta redirects or use a different URL as the entry page.
    Avoid meta redirects, register another URL

  4. Code on alternate page is not linked correctly from registered URL
    This concerns the "PASS-L" (Need Help?) test, which is accepted by a growing number of RMs.
    Display code on registered URL; learn to PASS-L

  5. URL does not exist or is otherwise mistyped
    Naturally the page must be there for the checker to reach it. Entering an invalid URL (whether through transposition, omission, or addition of characters or failure to observe rules of case-sensitivity) will cause a 404 error (page not found) to come back on the test. This one is tricky to catch because you load your site and see the code but the test FAILs. Try copying the URL you registered and loading it.
    Edit URL via Global Editing (where you can control the U#); edit URL via site manangement screen and obtain new code

  6. URL updated/revised but new code not copied
    Whenever the URL is altered in any way, a new U# will be assigned, meaning a new stack is necessary.
    Install additional stack; edit URL & merge stacks; edit URLs via Global Editing (where you can control the U#)

  7. Code is incorrect for the particular membership
    There are numerous reasons for a code to be incorrect, but the most common is #6. It's similar to the next explanation and may be tougher to discern from it as the incorrect code may display the NavBars anyhow.
    There are also cases where a member installs another member's (usually the manager's) NavBar code, making the site ID# is wrong.
    Delete current coding and install updated code

  8. Site displays a WebRing code with an outdated U#
    This is a complex version of "wrong code", because you still SEE and can use the navbar, which misleads you to believe the code is right. But in reality, that's not the code currently assigned to the membership (reason is unknown, could be due to a change you made or a system 'hiccup'.) It's most easily diagnosed by looking at the details of the checker test, where the ID will PASS, but the U# FAIL.
    Compare the U# in your code with what is generated by the system and make the needed change.

  9. Site displays another host's navigation instead of WebRing's
    This is similar to "wrong code" but the main difference is that you are displaying coding from a smaller host, such as Ringsurf NetRings or Bravenet SiteRings.
    Mouse-over links to see if they contain "webring.com" or another host's name. Copy and install WebRing coding

  10. JavaScript code contains extra characters or page breaks, is missing characters, or is otherwise flawed
    JavaScript code may not be altered to pass HTML verification tests or for any other reason, otherwise the checker won't recognize it.
    Use HTML; avoid altering JS

  11. Code is placed on JavaScript-generated frames page
    This is similar to #2, in that outside JavaScript can interfere with the checker. Generally frames are accused of being the culprit which is rarely true, except in the known instances on this page, but JavaScript-based frames are the most common problem.
    Use non-framed entry page or avoid JS-generated framesets
    Read more about frames and the checker

  12. Code is placed within 'nested' frames (frames within frames)
    While basic frames are not a problem, more complicated framesets can be. Keeping things simple decreases the chances of failure.
    Use non-framed entry page or avoid nesting frames
    Read more about frames and the checker

  13. Source Code Encryption
    A growing number of sites encrypt the source code to help prevent plagiarism, but the checker must be able to access the source code to make a determination about whether the code is installed.
    Avoid encrypting source codes or register a page that doesn't require encryption protection.

  14. Embedded Objects
    Sites using XHTML are unable (or perhaps unwilling?) to use the NavBar as it is intended. By embedding it in an object, the NavBar components are stripped from the source (similar to the previous point), preventing the checker from finding it.
    Don't embed in "object" calls. Use a regular HTML page for SSNB.

  15. CaSe-SenSitivity and Other Domain Incompatibilities
    Capitalizing a domain (such as entering http://www.WebRing.com) can be problematic if it forces a redirect to a lower-case version (you would see http://www.webring.com in the location bar despite how you typed it). Omitting a final slash (such as entering http://www.webring.com) can be problematic if the site host insists upon adding that slash (you would see http://www.webring.com/ in the location bar even if you typed it without the slash).
    Keep URLs in lower-case format. Add a slash to the end if you are not using a specific file extension in the URL or add the "assumed" file name (such as index.html)

  16. Spaces in Filenames
    Microsoft allows filenames to be saved as individually-spaced words (such as "http://mydomain.com/my home page.html") and this page will load properly for you. This URL would generally show in the location bar as "http://mydomain.com/my%20home%20page.html" The checker can handle "http://mydomain.com/my%20home%20page.html" but not "http://mydomain.com/my home page.html" (and some browsers are the same way).
    Keep filenames as "one-word"; manually install the %20 in place of the spaces when registering the page.

  17. Code is placed within another JavaScript call
    As suggested in #2 and #11, other JavaScript cannot be read by the checker.
    Avoid nesting your scripts

  18. Use of Only "noscript" Tag
    Either your site editing software or you stripped the JavaScript from the code, leaving only the "noscript" HTML. This only displays as a NavBar on JavaScript-disabled browsers, thus the majority of visitors won't see that coding. As a result, it's a natural FAIL.
    Leave JavaScript intact; acquire and install "proper" HTML coding to use in lieu of JavaScript

  19. Site host "time out"
    Some part of your page is unresponsive when being loaded by the checker. The page must load completely for it to be viewed. This is easiest to recognize because the checker result will state "Status: Time Out" and the details contain "fetch=Can't Retrieve Page"
    You'll have to isolate the server which is not loading completely and determine what, if anything, you can do to overcome it.

  20. Migration failed or was incomplete for a membership
    This one may be difficult to detect, as it may appear to either the manager or member to be properly migrated, it's only after both parties compare notes that they find it's not. Failed or partial migrations will prevent a membership from appearing on a stack.
    Complete migration or have manager assign membership to correct ID

  21. Unmigrated Site Using Yahoo!WebRing Code
    This does not mean Y!WR codes don't work. This only refers to sites migrated to Yahoo! but not subsequently migrated to WebRing. The membership must be associated with the WebRing ID shown in the Yahoo! code for the checker to pick it up.
    Migrate, then compare codes for possible changes.

  22. Link to alternate page contained within image map
    The checker simply is not configured to read image maps
    Use only text hyperlinks or just put the code on the registered URL

  23. Link to alternate page uses a graphic
    The checker cannot determine if the graphic uses the word "WebRing" on it and it's specifically looking for the word.
    Use only text hyperlinks or just put the code on the registered URL

  24. Cookie Acceptance Required
    Some WebTV sites require cookies to load their pages. Since the checker is not cookie-enabled, WebTV refuses the request, causing the site to fail.
    Contact the manager (Need Help?) to request exemption from automated management or host Rings on a non-WebTV server

  25. Target URL Requires Log-in
    Some sites such as adult MSN or Yahoo!Groups and even some Forums require being logged into an account in order to access (You may not realize this one as you are likely logged in when viewing or editing your site). The checker doesn't have the ability to log into an account (and most visitors won't want to create an account just to browse a site).
    Must use a page that is publicly accessible

  26. File Extensions
    Certain file extensions, including but not limited to .jsp (Java Server Page) and .asp simply cannot be read by the checker.
    Contact the manager (Need Help?) to request exemption from automated management or use an HTML file for Rings

  27. HTML Versions of Codes with 'Select Tags'
    HTML savvy Managers may use drop down menus for navigation commands. To accomplish this, 'select tags' from email forms are used. But the checker does not examine select tags in the HTML version. This situation is relevant only to those using an HTML version of this type of customized code. The SSNB is unaffected.
    Contact the manager (Need Help?) and inform him of this, but since he's unlikely to rewrite his code, use the SSNB or one of the Code Options in order to get a PASS result.

  28. Opening "html" Commands That Do Not Close
    Check your source code. At that top should be an "HTML" command (along with "body") and at the end should be an opposing "/HTML" and "/body" tag. If you find that one or both are missing, this is the likely source of your FAIL.
    If you write your own HTML, correct this error. If you do not write your own HTML, meaning the site layout is provided by your host, alert them to this problem.

If you are certain that none of the above pertain to your situation, don't bother Support. They'll refer you either to the manager or to here. Instead, post to me directly in the Member Resource & Tech Support Forum hosted by WebRing. Most members will be directed back here, because this page covers nearly every situation. But a small number of you may actually find a different solution.


Return to the Users' Guide Main Page