Possibly the biggest one from my perspective would be the data validation: most modern web applications are pulling data from some kind of data source and rendering it, then interacting and modifying the data based on user interaction.
As I said initially, with a site that deals with data and stores it in a database, you should always start from a known data state (by restoring a backup of a known database into the web application database) and validate that the state of the data when your tests finish is what you expect. You can do this either on a per-transaction basis (which gives a more granular flow and isn't affected as much by a transaction failure earlier in the run, but is much more complex to implement) or at the end of the test run as a single baseline comparison (if an early test fails to complete, you will get a lot of comparison errors due to the number of transactions differing).
If you can't start from a known data state, the best you can do is per-transaction checking to ensure that the data you enter through your tests is correctly saved to the database. Either way, you will need to know the structure of your database and how that relates to the data on the screen (which can be quite different).