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. =)
If you think that UML models and diagrams only serve to communicate the architecture to technical people, you might probably be wrong, since architecture has to be communicated to a lot of other people, especially to those sitting in management with black suits and wanting to have some good reasons why money/time/resource has to be spent in order to realize a specific architecture.
That's also one of the reasons, why UML provides such a large set of different diagrams, which simply aim at different stakeholders with different (technical) knowledge.
Another reason for using different diagrams is simply the complexity of a project. In general you can have static (concerning structures), dynamic (concerning runtime behavior) and allocation (concerning environment mapping) views on a software project. Including them in one diagram would result in a big mess, so you split them up to just have a part of the overall-complexity in one diagram.
Relating to your approach, the component diagram is a static view on the system and the sequence diagram is a dynamic view on the system, so this is quite a good start for documenting architecture.
It's also clear that you don't have the time/money to document each and every possible view/diagram for your system. The consequence is that you have to choose the most important ones, but between which criteria? One the one hand, you have to determine the main kind of complexity in your system. Since web projects have mainly runtime behavior, you would concentrate on the dynamic view of your system. On the other hand, quality attributes like performance or availability play an important role in determining your efforts in documenting, since they are cross-cutting your whole project and therefore cost a lot if you missjudge them.
And as I mentioned above, if black-suited guys hear the cost-bell ringing, they want to get thorough justification and what would in this case be better than having some diagrams in your pocket describing the most complex system-parts with stakeholder-adjusted complexity?
In order to get a general understanding on architecture documentation, I strongly recommend the paper by Philippe Kruchten Architectural Blueprints - The 4+1 View Model After you have read it, it might be much easier for you to determine which models/diagrams you need.
Best Answer
The most important is that it is clear from the use case description that a choice must be made between the search and the browse functionality.
In your diagram, the 'add to basket' use case should
<<include>>both the 'search products' and 'browse products' use cases (assuming that the choice for searching or browsing is made from the 'add to basket' use case). If you really want to show that those included use cases are mutually exclusive, you can add a UML constraint{ mutually exclusive }linked to the inclusion arrows, but that is completely optional.