When selecting a testing method you should always first ask what the goal of the testing is, for no one method will suit all possible purposes. At the most basic level, different methods are good for discovery, while others are good for validation.
Paper-prototyping is a testing method for discovery and understanding, and is ideally used early in the design cycle.
You certainly can use paper-prototyping to test specific sections of websites, especially those which represent a work-flow. Paper-prototyping has the advantage of being quick and simple to test several alternative approaches, as well as supporting rapid redesign (possibly even while a user session is still in mid-train).
There are also some meta-benefits to the process.
Benefits of Paper-Prototyping:
Paper prototyping is very good for early stage testing of your interface workflows, to discover if you have any mismatches between your design model and the user's inherent mental model of the task. You can't (easily) get new users to arrive at your site with a changed mental model in mind, but you can always change your design model to suit. As much as possible you want to discover the user's mental model and preferred workflow, not simply refine an existing UI by papering over the incompatibilities.
Using lo-fi prototypes makes it easier for your users to suspend their disbelief and make it easier for them to think on a more abstract level (i.e. closer to their mental model of their problem, instead of adapting their understanding to the quirks of the interface before them).
Also, use a collage mix of rough line drawings, fine art sketches, cartoon images, and even some printouts of wire-frames. The (feigned) lack of respect for the honor and integrity of your "art" will give licence and permission to your participants to criticise the designs they are interacting with. (Sometimes test participants are too polite, and don't want to say you've made a design mistake, or they resort to giving socially acceptable answers).
Using lo-fi prototypes will also make it easier to kill your babies - this is not the time to have your designers fall in love with their creations. Prototypes are meant to be thrown away.
Paper prototyping is also good for testing workflows and basic UI interaction without the distractions of content, branding, styling, etc. It is actually a good thing to discover where in the process users will have trust issues, or get confused as to whether the content is from the website are is a third party thing. Once you know where these weak spots are you can ensure they are addressed, without wasting time and effort addressing these issues in places where they don't have an impact.
Some tips for when you do your paper-prototyping testing:
do paper prototyping very early in the design cycle, possibly before you've even progressed onto making wire-frames.
get your entire design team involved in making all the various parts - doing this early can serve to address the storming and norming phases of team building.
don't get your best sketcher to do all the sketches. It's OK to have a mix of rough line drawings with fine art sketches. (This collage effect communicates that you're not interested in execution details)
use lo-fi sketches where possible - you want to keep the users in the mode of exposing their mental model, and not getting hung up on execution glitches. You also don't want your designers getting tunnel vision and obsessing about execution details.
sketch up interface "blanks" and photocopy them, ready for quick re-design (eg. a variant of a drop-down menu would thus only need the menu item names added, no extra drawing needed).
use print outs of existing wire-frames for less critical pages (less critical for the testing objectives, that is). Go ahead and overlay lo-fi paper elements if you need to make a quick change.
ask the participants to use the thinking aloud protocol.
have at least two people involved on your side: an operator, and an observer.
We used paper-prototyping on a custom checkout flow of a service. This particular service had two co-dependent sections and we weren't certain whether to get the user to complete Module A before Module B, or vice versa. By testing, and getting the user to follow the think aloud protocol, we uncovered some latent mental model mismatches with one of the approaches and figured out the preferred workflow.
We also identified another redundant section earlier in the workflow and eliminated that step entirely (it was a product selection and preview step ... but at launch we'd only have the one product so it was rather pointless, even if it did present a pretty picture and a bullet list of product features).