Do both. Integration tests serve the purpose of checking that two pieces of functionality that should work together do work together. BDD (or any other form of acceptance) tests verify that the user-visible feature works according to the needs of the customer and the business. If the end requirement is that someone can access a website, you must do that with a non-integration test because that's how the user will interact with the system.
All that being said, don't get hung up on terminology. Call the tests whatever you want. At the end of the day the software needs to be tested. You don't get bonus points for testing them with BDD or with functional or unit tests. The only bonus points are whether or not the software is as bug-free as possible.
In a perfect world you would have a huge pile of unit tests that test each unit individually, a smaller set of integration tests that verify the integration of each of those units, and an even smaller set that verifies that the UI is functioning properly and calls the appropriate functions. And, of course, an even smaller set of exploratory tests that let your trained quality analysts use their intuition to find the really deep, gnarly bugs that are hard to catch in an automated fashion.