Lately, clients have been asking about SharePoint site indexes more and more, so we wrote this blog to help explain what a site index is and why you would want to use one.
What is a SharePoint Site Index?
A SharePoint site index is simply a list of all the sites in a SharePoint environment (including site collection root sites and subsites). I always export these to Excel so the list can be filtered and sorted as necessary. The list also contains other relevant summary data about each site, including:
- Its URL
- Which site collection it belongs to
- When it was last modified
- How much content it contains
- Whether it contains workflows or InfoPath form libraries
- Whether it is accessible to all users
Why is a Site Index Useful?
A site index is useful because it helps us understand the full landscape of a SharePoint environment. Additionally, because a site index is compiled from several different reports, we can dig deeper into some of the information it conveys using ad hoc queries on those reports. For example, the site index itself will only list the number of lists/libraries that a site contains, but we have the underlying data to dig into the specific lists/libraries on an individual site if we need to.
Better Estimates and Planning
With its summary data, we can use the site index to do things such as make better migration time estimates given sample migration data from only part of the environment. We can further determine how to best orchestrate complex migrations, whether those complexities come in the form of restructuring site hierarchies or splitting the migration up into waves to better manage downtime inflicted on users.
Capture Project-Related Data
Finally, we can use the site index to capture project-related data regarding individual sites. For example, we may want to work with the client to identify which sites we need to test following a migration or which sites we want to delete.
We may need to identify the people responsible for individual sites. We may also want to flag some sites as being high value/traffic/complexity, warranting extra attention paid to those sites during a migration. And we may need to identify sites that are empty or no longer used.
The structure of the site index allows to identify sites by adding data, highlighting, etc. The data in the site index helps us identify sites that fit the criteria we’re looking for. Additionally, we can leverage the site index to create communication-focused lists for end users, identifying things such as the URL that sites will have once they are migrated, scheduled migration dates/times, or who site owners are so that end users can work directly with them if they have questions about how a migration will impact their content.
What Shortcomings Does a Site Index Have?
For all its benefits, I would be remiss if I ignored some of the site index’s shortcomings.
First, it only represents the state of a SharePoint environment at the time when its underlying reports were run. As we know, the makeup of SharePoint environments continuously evolves, so the data in the site index must be taken with a grain of salt. Long projects – or projects in which mass changes are made to a SharePoint environment – may warrant re-running a site index. Ultimately, checking an assumption made from the data against the environment itself is still important.
Second, the creation of a site index usually requires some data manipulation to ensure that the index represents what you intend. SharePoint does not always present its data in obvious ways, and some data varies between environments. For example, user data is often portrayed differently between clients. As such, identifying users and site owners via the site index is never totally accurate, though this does not negate the usefulness of the index in pointing out the right direction.
Third, the amount of useful data that can be included in the site index varies depending on the methods used to collect the underlying data.
How Do You Create a Site Index?
Currently, a site index is created by running either PnP or PowerShell scripts – or by running a standard set of ShareGate reports – and then compiling the data from those reports into a master index via Access database queries and (sometimes) Excel macros. These methods are slowly being revised and a closer-to-push button standard is being sought, but this has been slow to develop for lack of time.
For now, the best way to get a site index created is just to consult with SharePoint experts like us.
