The web is made of web pages with links between them. Your pages should take part. They should have URIs which people can use to make links to. Every user sees this as the ability to make a bookmark.
If you make a web site using simple tools, and put some file folders into a web site, then normally your web pages will have URIs, and people will be able to bookmark them. if this is the case, you can ignore this page.
The problem of web pages which are not bookmarkable only occurs when someone has gone to a lot of trouble to make it not so. Sometimes this is done deliberately, sometimes accidentally. Here are some traps to avoid.
HTML frames are a convenient way of making a navigation or advertising bars which stay the same while the main panel of information changes. Unfortunately, they also make it easy to break bookmarkability. The URL which the user sees, and bookmarks, is the one of the frame set, the whole thing, not the main panel.
You can in fact use style sheets to get the same positioning effect as frames. This has the advantage that browsers which don't understand the style, or have it turned off for accessibility, will display the information in sequence as a web page. You can also change the formatting for print or for small devices by using media-specific style sheets.
In general, frames are a bad idea. Try to use style sheets instead.
Another "sophisticated" but broken technique is to put a large session number into the URI. The session number contains information about the current user, and also a timestamp. If any URI is used as a reference, it will seem to work to the original user and only for a short while.
Cookies were invented to connect the page requests which belong to the same session, or to the same user. If used with due respect for the user's privacy, then they provide a great benefit in, for example, keeping a shopping cart. An alternative system stores the session ID in the URL. This is not what the URL was design for. It was designed to identify the web page, not the session. A advantage is that this will work even if a user does not have cookies. A disadvantage is that proxy caches and user caches do not save the information, even though it may be exactly the same as for previous sessions. Another disadvantage is that it can mess up the bookmarking -- and bookmarking can mess it up.
Travel agents, bank and shopping sites are typical sites which make this error. The result? I email a pointer to a product I have found to a friend, she clicks on it and gets: "Session timed out: please log back in", with a pointer to the home page.
If you use the URL to encode a session ID, and someone bookmarks it or emails it to a friend, then your system will be confused. Suppose a person, while shopping on your site, notices a nice sweater and emails (or IMs) the URI to a buddy. The buddy clicks on the link, decides to buy it and it is charged to the original person's account. This, I hope, is rare.
More common is the failure of the link. The first person browses a site, finds a nice sweater, and bookmarks it. They come back next week, and decide to buy it. Accessing the bookmark, the site responds with an error message, because the session has timed out, or the access is coming from a different computer.
It is quite reasonable to put a time out on the information (cookies for example) used to define a session. It is reasonable, therefore, to re-prompt me for authentication if I follow the link after the session has expired. However, after I have re-authenticated, I want to find myself back in the page I was at. And probably, if I was interrupted shopping, I want to have the same things in my shopping cart.
Of course, one could clarify with the user. "We have lost track of your original shopping cart - you have an empty cart now.", or "Did you want to continue the shopping you were doing on Friday, or start fresh?". Most good sites now seem to keep a shopping cart more or less forever, and allow one person to mail the URL of an item to another so that everything works.
It is normally best not to use the URL to identify the session.
When a web browser asks a server for a web page, the command it uses is GET. The only reason you need to know this is that when you make a form which has some action, like confirming a sale, the form submission is done with a different command: POST. POST is used when a commitment is made, GET is used just to browse information.
A classic mistake made by many web sites was to use a form for navigation, and use POST even though the action is just to retrieve information.A classic example is the bank site, where a form has a pop-up menu for selecting the bank account, and a submit button marked "account details." The button is mistakenly set up as a POST form. The bank receives a command from the browser and just returns the account details. At this point the user cannot bookmark the account. Of course, the user's checking account details maybe the one thing he or she looks up every day. Instead of selecting a bookmark, he or she has to log on and wade through a series of forms.
Also, the browser does not know that the account details are just fetched information. As far as the browser knows, the user may have committed to a transfer. So when the user uses the "back" and 'forward" keys to review the last few pages, the browser will typically refuse, or prompt the user, "repost form data?". Not the required behaviour.
There is a particular control-oriented philosophy about web site design, used by some sites and some site-building tools, which attempts not to enable the user but to constrain the user. The idea is to control the user's experience completely. These sites typically have entrance tunnels -- the home page sequences which forces one to sit and click through a little presentation before accessing the real site. These are a disrespectful waste of user's time in almost all cases. Similar control is typically attempted throughout the site. To get this level of control of the user experience, the site must stop the user using the "back" button. This is typically done by using POST instead of GET, and running a script which turns off the browser back button.
If you are tempted to use this form of design, or if a consultant offers it, stop. Don't. Make a real web site. The ability to link into the data is too important to throw away.
If you need authentication, there are ways of doing that. When someone comes back to a site by a bookmark (or a browser left sitting for a few days) it is reasonable to be prompted to log in again. But then one wants to be at the selected information, not back at the entrance to the site.
There are a number of reasons why people end up making a web site in which the pages do not have URIs. This doesn't only affect Bookmarks, it affects any links or references to the information. Fortunately, awareness of this trap is growing, and many sites which used to have this problem have been changed to resolve it.