Credible, yes, accurate, perhaps.
Indexes are (sort of) like shortcuts to database content that SQL uses to increase performance. When database content changes by getting updated, inserted, deleted and such, the indexes change to keep track. An index is stored in "pages" and just like any other disk-based data, can get spread out physically so that reading through an index becomes itself not the very quick activity.
It's a good idea to defragment or even better rebuild every index in your database. Since they are always objects attached to tables, you can loop through the tables in your database and rebuild each index associated with the table.
Rebuilding takes a bit more resource than just defragmenting, but it does a more complete job. If you have a large or heavily used database, schedule this to take place when usage is low, such as the middle of the night.
For best results, it is good to follow the defragmentation of indices on a database with physical defragmentation of disk. If you don't have control of that, such as on a shared hosting environment, you can ask your host how often disk defragmentation is scheduled.
Here is a script you can run on your database ... connect to the database using SQL Server Management Service, and run this.
There are two instances of the text "MyDatabaseName" in this script - one right at the beginning, and the other embedded .... be quite careful to replace each of these with the name of your database.
You can run this manually once in a while, or schedule it. It will be interesting to see if this improves your website performance.
USE MyDatabaseName
GO
DECLARE @Table VARCHAR(255)
DECLARE @cmd NVARCHAR(500)
DECLARE @fillfactor INT
SET @fillfactor = 90
SET @cmd = 'DECLARE TableCursor CURSOR FOR SELECT table_catalog + ''.'' + table_schema + ''.'' + table_name as tableName
FROM MyDatabaseName.INFORMATION_SCHEMA.TABLES WHERE table_type = ''BASE TABLE'''
EXEC (@cmd)
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @Table
WHILE @@FETCH_STATUS = 0
BEGIN
SET @cmd = 'ALTER INDEX ALL ON ' + @Table + ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3),@fillfactor) + ')'
EXEC (@cmd)
FETCH NEXT FROM TableCursor INTO @Table
END
CLOSE TableCursor
DEALLOCATE TableCursor
by the way, the suggestion to move to SQL Server 2008 from SQL 2005 as a prescription to cure slow performance ... while moving to 2008 has some benefits, this kind of increased speed is not automatically one of them. if defragging or rebuilding indices on 2008 cures the problem ... the same would probably have cured the problem on SQL 2005 as well.