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.