Web pages are part of the visual presentation of your final implementation, and are not part of any UML Sequence Diagram language construct. Webpages would serve no purpose that is not alredy addressed within the current UML Sequence Diagram language and definition.
Additionally, by including a web page into any design document, you are presupposing a visual implementation. If you are strictly designing sequence logic, you should have NO preconceived notions as to how the visual implementation might look. (It's not a "website design diagram", it's a sequence-of-logic diagram.)
I find that you can almost always make a case to violate any guiding principle, design approach, teaming agreement, programming language paradigm, and even engineering "best practice". But these are (and should be) "red flags" that alert you to the fact that you are going outside of the original concept/reason for using whatever technique/tool/etc. you've chosen, and it will only lead to less rigor. Rigor, for its own sake, is not good or even necessary. But rigor constraining behavior for a specific goal is usually "A Good Thing(tm)", because it saves you from yourself - or from "misuing" (of sorts) the framework that you've selected.
Suggestions/frameworks/best practices exist solely to advise and constrain your behavior in favor of a particular outcome, and are based upon the combined experience of many, many very talented people. I don't recommend that you violate the UML Sequence Diagram construct by including webpages in the diagram, as this violates the rigor of the UML Sequence Diagram constructs, and it defeats some of its purpose (to remove visual - and other - considerations from what should be rather pure business logic and/or the interactions of your design).
I recommend that you stick to using the UML Sequence Diagram a little more literally - it's not a "website design diagram", unless THAT is what you WANT to make it. And if so, you might call what you are making a "website sequence diagram", though it seems to be a stretch...
It's up to you to use your tools as they suit your needs. But I wouldn't make this change lightly. =)
I would say go as high level as you can while still including all the necessary method calls, etc for your topic. My reasoning for this is that if you're including every single interaction then you might as well just write the code yourself.
Personally, I have always viewed sequence diagrams more or less as "guidance" for the implementer. I've never viewed them as living documents - if the implementation differs from the design I won't go update the diagram (unless it's different because my design was wrong). However, you're right in assuming that it largely depends on the audience.
If you have a team full of experienced developers with knowledge of your product, you should be able to leave a few things out here and there and trust them to fill in the blanks with their best judgement. In my case, I usually confine my sequence diagrams to a particular topic, say "Process XYZ", and only show method calls and object interactions that are relevant to that topic, leaving out things in between that are obvious or are defined in another diagram. If I'm writing a diagram for a junior developer who's learning the project and domain, then I tend to be more specific.
The only reason I would include every single method call and interaction is if you're actually generating the code from the model. For example, I've worked on some embedded systems where we generate our code out of a Rhapsody model, so obviously in that case you should include as much as you can.
Best Answer
There are a few things wrong in your diagrams.
First of all, your use of actors. An actor is something/someone outside the system you are modelling that needs to interact with your system. Actors are represented by a stick-man, because they are typically humans. Non-human actors can exist, but it is much harder to tell for non-human actors if they are correctly modeled as actors or if they should have been modeled as a part of the system itself.
The servers, printers, displays, etc., that your software runs on are most definitely not actors. These form an integral part of the system you are designing.
As actors are by definition outside your system, direct interactions between actors are of no interest to you. If you have a sequence diagram with a call/event arrow between two actors, then either it must be possible to remove that interaction without changing the meaning of the sequence diagram, or at least one of the actors should have been part of the system.
A proper use-case diagram offers surprisingly little information to the reader. It might be best to consider a use-case diagram as not much more than a graphical index to the use-cases that exist and their primary actors.
A use-case is an interaction between an actor and a system, where the actor uses the system to achieve a goal.
In your example, "login" is a proper use-case, but all the others are not. They are just steps that are taken as part of the "login" use-case. For a correct use-case diagram, you can just erase everything to the right of the "login" use-case.
The normal way to describe a use-case is just plain text, although supporting diagrams like sequence or activity diagrams might be used.