Plan the end-user search experience (Office SharePoint Server)

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

• Plan what users see when performing a query

• Plan what users see in search results

Search administrators can improve the relevance and presentation of search results by carefully planning the end-user search experience. The goal of such planning is to create a search experience that enables users to quickly find the information they need. This article contains information that can help Shared Services Provider (SSP) administrators and site collection administrators optimize the end-user search experience.

The first section of this article discusses:

• The search user interface for performing search queries.

• How to plan for custom scopes. This includes information about the default scopes that users use to filter the content included in each search query. Administrators can use this information to help identify when your organization might need to create custom scopes. This subsection also discusses how to plan any necessary custom scopes.

• Advanced searches and how properties can be used to filter search results. Administrators can use this information to understand the options they have for managing keywords and properties to optimize users' ability to perform powerful advanced searches.

• The benefit of using property searches with scopes. This includes how crawled properties relate to managed properties and how to plan for them.

The second section of this article covers search results pages and the features that administrators can control that affect what users see in search results. The section discusses:

• How to plan for keywords and best bets. This includes how to plan for effective keywords, best bets for a particular organization and how associating synonyms with keywords can enhance the end-user experience.

• How administrators can control the relevance ranking of particular sites to improve the relevance of search results.

• Describes the new federated locations feature that can be used to search multiple sources and combine results into a single search results page. This feature requires the Infrastructure Update for Microsoft Office Servers. For more information, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

• How to control how links appear in search results.

• How to plan for search-based alerts.

The abilities described in this article enable administrators to have a great deal of control of the end-user search experience. Although we recommend that you constantly evaluate the effectiveness of search queries during regular operations, good planning before the initial deployment can help create effective search queries from the start and reduce future administration costs.

Plan what users see when performing a query

To effectively plan for the configuration choices that help you realize your goal of helping users find the content for which they are searching, it helps to first consider what end users see in the user interface.

Search user interface levels

To understand how to plan the end-user search experience, it is helpful to first become familiar with the user interface that end users use when performing queries. As you might expect, this user interface is straightforward. The focal point of this user interface is a search box where users can enter search queries. A search box is provided on all non-administrative pages in the site collection and also in the Search Center. For example, the search box appears, by default, at the site level and the list level. The following sections describe search user interface at each level of the site collection.

Site-level search user interface

The site-level search box (callout 2) is a text box on the top-right corner of Web site pages in which users can type their search queries. After users type a query, they click the Go Search button (callout 3) to run the query. Advanced users can click the Advanced Search link (callout 4) to use the Advanced Search page to construct queries. Information about the Advanced Search page is provided later in this article.

The first thing you might expect users to ask when looking at a search box in a user interface is, "What body of content will my query be run against?" The Search Scope list to the left of the search box (callout 1) specifies the body of information in the content index that the query will be run against.

This enables users to perform queries against subsets of content in the content index, which improves the relevance of their search results.

List-level search user interface

The search user interface at the list and library levels looks and functions the same as the site-level search user interface, except that an additional default scope, called This List, is available. The list-level search box is at the top-right corner of each list and library in all site collections. The Search Scope list is set to the All Sites scope by default, but users can select another scope from the list.

Search Center search user interface

The Search Center provides a centralized and highly customizable user interface in which users can perform search queries. The Search Center consists of a search box for entering search queries, and a link to an Advanced Search page so users can construct advanced search queries. By default, the search box is set to the All Sites scope so users search across all content in the index. However the People scope, used to search for people in your organization, is also available on a separate tab. Administrators can choose to add tabs and associate them with custom scopes that users can use to query over different subsets of content.

Users go to the Search Center by clicking the Search tab on the top link bar (callout 1). Similar to the search box at the site-level, the search box in the Search Center (callout 3) is a text box in which users can type their search queries. Users then click the Go Search button (callout 4) to run their queries. By default, the All Sites scope is selected but a user can select another available tab, such as the People tab, to use a different scope to search.

Advanced users can click the Advanced Search link (callout 5) to use the Advanced Search page to construct queries. The Search Center uses the same Advanced Search page as the site-level search box. Information about the Advanced Search page is provided later in this article.

Unlike the site-level search box, the search box in the Search Center does not have an adjoining Search Scope list to the left of it, by default, for selecting different scopes. Instead, users click the tab (callout 2) that corresponds to the scope with which they want to search. Office SharePoint Server 2007 provides two default scopes in the Search Center: All Sites and People.

The following table shows the default scopes that are available in Office SharePoint Server 2007 and the levels at which they are available.

This scope	Enables users to	At this level	Customizable?
All Sites	Search across all content in the index	Search Center Top-level site Subsite Lists and libraries	Yes
People	Search for people	Search Center Top-level site Subsite Lists and libraries	Yes
This Site: Site name	Search across the current site and all of its subsites	Top-level site Subsite Lists and libraries	No
This List: List name	Search across the current list	Lists and libraries	No

Plan custom scopes

To understand when your organization might need to supplement the default scopes with custom scopes, you must first have knowledge of the default scopes. This section provides information about the default scopes provided with Microsoft Office SharePoint Server 2007. You can use custom scopes with scope rules to group certain content in the index into a set of content on which queries can be run. For example, you can make it possible to search a specific set of Web sites, or all Word documents that were authored by a particular person or were authored during a particular period of time, or any combination of these parameters.

Scopes that you create at the SSP level are called shared scopes because they are shared with all site collections that use that SSP. Site collection administrators decide which shared scopes to use and how to display them.

You can also create custom scopes at the site collection level, which makes the custom scopes available only to the site collection on which they were created. Scopes created at this level are sometimes called site-collection-level scopes.

Scope scenario

During content and site structure planning for a large organization, it is determined that human resources is a large division that delivers content relevant to all employees on several SharePoint sites and line-of-business applications. Therefore, the SSP administrator creates a shared scope for content relating to human resources.

The site collection administrator of the human resources site uses that shared scope and creates additional scopes at the site collection level. The site-collection-level scopes are for company policies and new hire information because those are core concepts that are relevant for the site collection. The site-collection-level scopes do not make sense as shared scopes because people searching in other site collections are unlikely to want scopes that are so specific.

Site collection administrators can either use the shared scopes as defined by the shared services administrator or copy the shared scopes they want to use in their site collection and modify them. They can then select the display groups in which to include each scope, such as the search box drop-down list and the Advanced Search page.

To summarize, SSP and site collection administrators first create the scopes that are needed for their organization and then a site collection administrator associates them with display groups to make them available to the search boxes that are associated with those display groups. Site collection administrators can associate one or more scopes with a display group. More information about display groups is presented later in this article.

When planning search scopes, you look at your information architecture to identify broad content sets on which people are likely to want to search. (For more information, see Determine the information architecture of your site.) Some of these content sets will span the information architecture across many sites, and some will span subsets of information within site collections. Site collection administrators decide whether to implement shared scopes or site-collection-level scopes for a particular site collection based on the needs of the users of that site collection. Content that is only relevant within certain site collections should be left for scope planning at the site collection level.

Plan shared scopes

Because certain site collections are tied to a particular SSP, all settings for a particular SSP affect all of its associated sites. The SSP administrator manages shared scopes for all sites that use the same SSP. SSP administrators can perform the following tasks:

• Create and edit shared scopes.

• Add scope rules to shared scopes.

• Delete shared scopes.

• Refresh changes made to scopes.

Shared scopes are visible and available for use by administrators for all site collections that are using the same set of shared services.

The following shared scopes are automatically created for each SSP and are available on the Search Center, by default:

• All Sites

• People

Plan scopes for site collections

During planning, each site collection administrator will want to create scopes based on the information architecture within the site. They can choose to create new scopes, make a copy of shared scopes (a copy of a shared scope becomes a site collection level scope), or both. For example, site collection administrators can add scopes by selecting shared scopes that are useful for people using their site collection, and then supplementing those scopes by creating scopes for the site collection.

The following table shows the actions related to scopes that can be performed by site collection administrators.

Site collection administrators can perform these actions on shared scopes	Site collection administrators can perform these actions on site-collection-level scopes
Choose how to display search scopes (search dropdown, advanced search, or both). Copy and modify a shared scope to use as a scope for the site collection. View the status. For example what scope rules they contain and the order in the scopes list in which they appear.	Choose how to display search scopes (search dropdown, advanced search, or both). Create site collection level scopes. Edit site collection level scopes (more information provided below). Add scope rules. Delete site collection level scopes. View the status. For example what scope rules they contain and the order in the scopes list in which they appear.

Site collection administrators cannot create or add matching rules to shared scopes directly, though they can copy a shared scope as a site-collection scope and modify the copy.

When creating or editing a new site-collection-level scope, you specify the following:

• Unique title.

• Description for the scope (optionally).

• Display group, sometimes called scope group. Site collection administrators can assign scopes to display groups to determine where they appear on the site. By default, Office SharePoint Server 2007 provides display groups for the search box drop-down list and the Advanced Search page. Site collection administrators can assign one or more scopes to any display group.

• Results page. You can choose to use the default search results page to display search results when this scope is used or specify a different page. Note that if you choose to use a different page, you must first create that search results page.

No site collection level scopes exist, by default, but each site collection has access to all shared scopes.

Plan display groups

Display groups provide a way to assign scopes to a particular search box. Site collection administrators have several options for configuring the existing display groups or they can choose to create one or more new display groups. Typically, a site owner identifies a particular need for a display group. For example, users of a particular team site might frequently need to search for content that is scattered across multiple document libraries. To narrow the body of content they are searching over, they currently must perform separate searches in different search boxes —for example, in the search box of each library — or construct an advanced query to filter the search results. To provide users with an easier way to perform this frequent search, the site collection administrator creates a display group and assigns the appropriate scope to it. Site Owners can then associate this display group with a particular search box — for example, a search box on a custom search page on the site. Users then use that search box to search over the content defined by the scope, in this case, the document libraries. Office SharePoint Server 2007 provides two display groups, by default:

• Search Dropdown   The All Sites and People scopes are assigned to this display group and it is used by the search box, by default.

• Advanced Search   The All Sites scope is assigned to this display group and it is used by the search box on the Advanced Search page, by default.

Site collection administrators can perform the following actions:

• Add scopes to any display group.

• Remove scopes from any display group.

• Create new display groups and assign the scopes they want to them.

• Change the order in which scopes appear in the Search Scopes list.

• Specify which scope is selected, by default, in the Search Scopes list.

Site owners can perform the following:

• Assign different display groups to the search box and the Advanced Search page in the Search Center site.

• Create new search pages using the Search Box and Advanced Search Box Web parts and assign the display group or groups that they want to use.

Plan scope rules

You define a scope by adding scope rules to the scope. Scope rules define what content to associate with the scope and what content to not associate with it. Scope rules added to a particular scope define the extent of the scope.

Each scope rule is based upon a particular scope rule type, which defines the properties, locations, and sources of content. The following table lists the scope rule types that are available to shared search scopes and site-collection-level search scopes.

This scope rule type	Is available to shared search scopes	Is available to site-collection-level search scopes	Tests content by
Web address (https://server/site)	Yes	Yes	Location
Property Query (Author = John Doe)	Yes	Yes	Single property
Content Source	Yes	No	A particular content source
All Content	Yes	Yes	All content in the content index

The All Content scope rule type is the simplest because it associates all crawled content with the scope. For each of the other three scope rule types, an SSP administrator can specify the behavior of the scope rule which determines the content to associate with the scope. These behaviors are described in the following list:

• Include   Items matching this rule appear in search results unless another rule removes them. When combining rules, this behavior is similar to the OR logical operator.

• Require   Items matching other rules must also match this rule to appear in search results. This behavior is equivalent to the AND logical operator.

• Exclude   Items matching this rule are excluded from search results even if they match other rules. This behavior is equivalent to the AND NOT logical operator.

Scopes will often be based on a single scope rule. However, there are good reasons to use scopes with multiple rules. You can create scopes based around a specific theme or conceptually-related set of content. To do this, you can include and exclude several locations, properties, or a combination of locations and properties that are conceptually related. The logical combination of rules determines the content that is either included or excluded from the scope.

Using scope rules that are based on location

You can create rules based on the location (Web address or UNC path) of content using the Web Address scope rule type. Several usage scenarios require rules of this kind, including searching for content in the following locations:

• In a group of document libraries.

• Within a set of folders in a single large document repository, for example, when searching a company archive.

• On external sites for a particular subject.

• On other servers in your organization.

Each Web address scope rule contains a single location, defined by a single folder, domain name, or server name. Depending on what set of content you want to make available in a scope, you add matching rules until all relevant locations are included in the scope and all irrelevant locations are excluded. Examine the information architecture and site structure planning to help you decide which locations to include in each scope.

Using scope rules that are based on managed properties

You can base scope rules on a specific value for a single managed property using the Property Query scope rule type. Before you create such a scope rule, verify that:

• The managed property that you want to use exists, either because it is a default managed property or was created by an SSP administrator.

• The managed property is configured to be available for use in scopes. Several managed properties are created but only a few are configured to be available for use in scopes, by default. Only managed properties that SSP administrators have specifically made available for scopes can be used in search scopes.

  Note

  SSP administrators can enable a property to be available for use in scopes by using the Edit Managed Property page for the particular property.

After the scope rule is created, each item of content that matches the property query is tested against that specific value and included or excluded based on the rule. Rules based on properties can only be queried by using the Is exactly operator and not against other operators such as Contains.

For example, a site collection administrator for a sales portal site can create scopes for each sales office by using the SalesOffice managed property and setting the value for the rule in each scope to the value for the relevant office. Because this managed property is used to define the scope, the search results will include only content for the sales office when using this scope.

When your organization plans the managed properties for your SSP, consider scopes. To create a scope for a certain set of content, you must ensure that there are properties of that content that are mapped to managed properties that can be included in scope rules.

Using scope rules that are based on a content source

There are several reasons an SSP administrator might create additional content sources. They are typically created to crawl content on a different schedule than other content. Often an SSP administrator will create a separate content source to crawl content that is on a different SharePoint farm or on a file share, for example. If a content source exists that already encompasses the content that users what to search over, for example, a file archive, an SSP administrator can create a shared scope with a scope rule (content source type) to enable users to search over that portion of content.

Only shared scopes can contain scope rules that are based on a specific content source. This scope rule type is not available to scopes at the site collection level. Your content source planning can help you identify sets of content that are easier to administer when they are on separate content sources.

For each content source that you plan, consider whether the content that was indexed using that content source is something that would make sense grouped together in a shared scope for people using the site collection. If so, you can add a scope rule for that content source.

Also consider if the content source can be divided up into smaller bodies of content that people might want to search for. If so, you can combine scope rules to specify the content source with other scope rule types to create a narrower scope.

For more information about planning for content sources, see Plan to crawl content (Office SharePoint Server).

Using the All Content scope rule type

When you create a scope rule using the All Content scope rule type, all content in the content index is available to the scope. If you want to create a narrower scope, you can add scope rules to a scope that uses the All Content scope rule type to exclude particular content from the scope.

Excluding content using a scope rule with the exclude behavior

The All Sites shared scope can be copied and used as a starting point to include all content in the content index. Then you can add scope rules that exclude content from search results to create scopes that are broad but do not include a certain set of search results. It is sometimes easier to use a copy of the All Sites shared search scope with exclusion rules than to create a complex search scope containing rules that include every subset of content on the site.

Regardless of whether you start with a copy of the All Sites shared scope or another scope, you might want to consider adding scope rules that exclude content as a separate step from adding scope rules that include content because reasons to exclude content from search results can differ substantially from the reasons to include content.

Example of scope planning

Contoso Corporation has an IT services division, a customer service division, and a sales division. Each of these three divisions has its own site collection, and there is also a central portal site collection for company news and human resources information. All crawled content is indexed into one content index.

Because the content for each division is distinct, the SSP administrator creates a separate content source for each of the three divisional site collections so each can be crawled on a different schedule. The SSP administrator also creates a fourth content source used for crawling the central portal site collection that contains the human resources and company news content.

By default, all content that has been indexed from each of the site collections is included in the All Sites shared scope that is available to all site collections. The SSP administrator creates a separate shared scope for each divisional site collection and then creates a scope rule for each shared scope that includes the appropriate content source for each site collection's shared scope.

For example, for the Customer Service division, the SSP administrator creates a scope called Customer Service, and then adds a scope rule to that scope. When adding the scope rule, the SSP administrator selects Content Source as the scope rule type, selects the Customer Service content source from the list of available content sources, and then selects the include behavior to include all items crawled using that content source.

The following table lists the shared scopes that have been created by the SSP administrator at Contoso Corporation.

This shared scope	Contains this content
Services division	All content on the IT Services site collection that was crawled using the Services Division content source.
Customer Service	All content on the Customer Service site collection that was crawled using the Customer Service content source.
Sales	All content on the Sales site collection that was crawled using the Sales content source.
Central Portal	All content on the Central Portal site collection that was crawled using the Customer Service content source.

In addition to the shared scopes created by the SSP administrator, the default All Sites scope includes all of the crawled content in the index. The All Sites shared scope is available, by default, to all site collections.

The site collection administrator for each division decides to use the All Sites shared scope and the shared scope that contains the content for their site collection, but none of them plans to use the Central Portal scope, even though it is a shared scope. That option will only be available from the Search Scope drop-down list in the central portal site collection.

The site collection administrator for each division makes copies of the shared scope that the SSP administrator created for their site collection. (The copies of the shared scope become site collection-level scopes.) Each site collection administrator then adds scope rules to the site collection-level scopes to target only the most important set of content that their users want to query against when using those scopes.

For example, the site collection administrator for the sales site collection creates scopes for content related to each product line, based on the managed properties of marketing documents and other content, and the location of related team sites and document libraries.

Worksheet action
Record your decisions about scopes, scope rules, and display groups in the "Plan scopes" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Advanced Searches

In many cases, users type a keyword phrase in the search box and then click the Go Search button or press Enter to execute their query. If this technique does not produce the result they are looking for on the first few pages of search results, some users will give up. However, advanced users tend try again by using a more advanced query to target the content they are looking for.

Very advanced users can construct advanced search queries in the search box. For example, to find content that contains the word "negotiate" that was authored by Bob Smith, they could type the following query in the search box:

negotiate author:smith

However, most users are not familiar with the syntax required to construct advanced queries in this way. Therefore, most users construct an advanced query by using the Advanced Search page which enables them to target the content they are searching for using syntax. The following table describes the options on the Advanced Search page that are related to keywords.

Find documents with this option	Does this
All of these words	Searches for content that contains all of the keywords the user types, but the words do not have to be in the content in any particular order.
The exact phrase	Searches for content that contains the words the user types in the exact order.
Any of these words	Searches for content that contains any of the words the user types.
None of these words	Searches for content that contains none of the words the user types.

Users can also use the Advanced Search page to narrow their search to a specific language or document type. Finally, users can select property restrictions to filter their search results based on whether the value of the property they select matches the value that they enter. For example, users can select the Author property, select the Contains inclusion operator, type a value, and then click Search.

Several properties, called managed properties, are provided, by default, such as Author and Title. However, most of the default managed properties are not made available to use in scopes. SSP administrators choose which managed properties they want to make available to scopes and can create additional properties to meet their organization's needs. Managed properties that are enabled by the SSP administrator for use in scopes are available to all site collections.

Plan properties for search

One way to organize content in your site collections in a way that can be effectively searched is to group content that has a common theme in the same location. This way, you can take advantage of the default scopes at the site and list level for searching over your content. For example, you can create a site to store all the information for a particular project. Within that site, you can create separate document libraries and lists to store different kinds of information related to that project. Users use the default This Site scope to search over all content in the site or the This List scope to search on content in a particular list or library in the site. SSP and site collection administrators can create custom scopes as needed for users to search over different portions of content.

Although this is a relatively easy way to organize your content for effective searches, this approach by itself does not meet the needs of all organizations, especially when a large amount of content is being searched. Some reasons for this are:

• It is not always possible to organize all content with a common theme in the same location.

• Even if all content with a common theme is organized in the same location at deployment, content can become scattered across a site collection over time.

We recommend that you organize your content by location when it makes sense to do so, and then supplement that organization by using properties.

Managed and crawled properties

When content is crawled, the crawler also crawls the metadata properties associated with that content. Crawled properties include the metadata of content that is stored in files, databases, and line-of-business applications used by your organization. Crawled properties can represent different kinds of information, such as author, title, and e-mail address.

In previous versions of Microsoft SharePoint Products and Technologies, you could reduce property duplication by mapping some properties to other common properties, but many properties confused search results because they weren't relevant. Thus, relevant properties were hard to find amid the many irrelevant properties.

Office SharePoint Server 2007 mitigates this confusion by enabling SSP administrators to create managed properties. They can then map crawled properties, which are the properties that the crawler collects and adds to the property store when crawling content, to managed properties that are used by search queries.

The relationship between managed properties and crawled properties is a simple but powerful one. SSP administrators can map one or more crawled properties (the properties discovered by the crawler) with managed properties (properties that can be used in scope rules and queries. This mapping is important because many crawled properties contain the same kind of metadata and crawled properties often have names that are not intuitive. For example, by default, the crawled properties named "Mail:6" and "Office:4" are mapped to a managed property named Author. This is because the values of these two crawled properties contain the name of the author. This mapping of crawled properties to managed properties eases administration and benefits users. Administrators benefit because they have fewer properties to work with when creating scopes. End users that construct advanced queries in the search box benefit because they also have fewer and more intuitive property names to remember.

Managed properties have the following benefits:

• Users can use managed properties to construct queries in the search box that filter search results.

• You can use properties on the Advanced Search page to enable end users to easily filter search results.

• Site owners can customize the Advanced Search page to use different managed properties.

• SSP and site collection administrators can create custom scopes with rules that filter search results based on queries. End users benefit from advanced property-based queries without the need to learn how to construct an advanced query.

Several managed properties are created and mapped to crawled properties, by default. SSP administrators can map additional crawled properties to existing managed properties and create new managed properties.

Using properties in queries

For the value of crawled properties to affect a search query, the crawled properties must be mapped to a managed property and the user must perform a search against that managed property. Including the values of too many crawled properties can have a negative effect on search relevance and performance.

If you want to use the manage property in a scope, you must make the managed property available to scopes. However, you do not need to do this to use the managed property on the Advanced Search page or as part of a query in a search box.

Administrators planning the initial deployment of Office SharePoint Server 2007 should record the initial set of managed properties planned for the search service for every SSP used in the deployment.

Many of these crawled properties can be found by looking at the properties of business data applications and the properties displayed in applications for content types such as Microsoft Office Word or Office Excel documents.

If you have access to a test server, you can crawl high-priority content and use the crawled properties that appear to help with planning.

You can make the content on your site easier to find by carefully planning your managed properties and how you implement them. When planning your deployment, we recommend that you keep the number of managed properties to a minimum. This means carefully considering what properties are most useful for your organization and deploying those as a starting point. You can always create additional managed properties after deployment, if needed.

Plan managed properties

One practical way to identify potential managed properties is to examine your existing content and its high-priority metadata. If you have access to a test farm prior to active deployment of Office SharePoint Server 2007, you can crawl your content and see what crawled properties appear, and use those properties to identify part of your information architecture. However, most organizations will benefit from planning information architecture on paper before staging a deployment, because it can help to focus your planning and identify content and processes that are not as well-organized as they could be.

The key to creating a useful set of managed properties is to determine the most important concepts and find properties in your content that you can map to managed properties that enable users to find relevant content when searching. Mapping more properties increases the size of the search database, and reduces performance accordingly, so it's a good idea to map properties only when you are confident that the mapping is relevant.

It is difficult to discover properties of content without first crawling content. Therefore, it is best to wait to plan managed properties until you already have a good idea of the content of each site collection. Then, on a test server, you can crawl all that content so that you have a list of crawled properties to compare against your information architecture when creating managed properties. It can be difficult to map properties even after crawling content because it is difficult to identify the content type or application that uses the property. If you are unsure of the nature and content of a particular property, you might want to set up a mapping in a test environment and experiment with searches over this property.

Many of the most useful managed properties are automatically created when Office SharePoint Server 2007 is installed. Use these managed properties as a starting point when planning your other managed properties. The automatically created properties include:

• Author

• Description

• Site Name

• Type

• File Size

• Last Modified Date

• URL

• Title

Keep in mind that in order to effectively search by using properties, the crawled properties must first be assigned values. For example, if you have a document that has a property that maps to a managed property called Author, and no value is assigned to that property on that document, the document will not be displayed in search results when users query using the Author property for a particular author.

Avoid duplicating managed properties

Some properties are fairly basic and might appear as different properties in different types of content. Examples include the Author and Title properties for documents.

The most important thing you can do with these basic properties during planning is to reduce duplication by creating one set of managed properties and mapping the crawled properties with the same meaning to properties in the set of managed properties. In the case of the Author property, you can map each unique appearance of a crawled property for authors with a single Author managed property.

You can map one or more crawled properties to one or more managed properties.

You can choose to prioritize multiple crawled properties so that if more than one property is found during crawling, only the value of the highest priority property is used for queries using the managed property or properties. If you don't prioritize crawled properties, values for all crawled properties mapped to the managed property are used for queries, so that the managed property becomes multi-valued. This means the search result returns results for all content that contains values for any of the mapped properties that match the query. A sensible approach for a single-value property is to choose the most common crawled property as the managed property, and then prioritize mapped properties by how often they occur. It is not always easy to determine which property is crawled most often, but one strategy is to prioritize properties that you know are associated with commonly used applications.

Be careful when mapping properties that you do not map poorly matched or irrelevant properties because imprecise mappings can actually reduce the relevance of search results. If possible, test searches for managed properties before initial deployment, and plan to review usage data for search queries during normal operations to fine tune the properties you have mapped.

Add properties to present key concepts in the information architecture

In addition to the crawled properties that are mapped to managed properties, by default, other crawled properties might clearly map to concepts in your information architecture that are not already captured by existing managed properties. For example, a company might identify customer service as a key business process in its information architecture. Key concepts associated with customer service in the information architecture might include customers, customer service representatives, and customer service regions.

For each concept in your information architecture, ask yourself if there's a crawled property that represents this concept that can be mapped to a managed property. If so, make the property a managed property.

Scenario

A line-of-business application tracks customer and employee data, and the properties of that data are likely candidates for managed properties after they are registered in the Business Data Catalog and crawled as part of a business data content source. You might also identify crawled properties for applications that should be mapped to these managed properties, for example, a customer service representative identifier (ID) property in a separate data application, or an Author property for an application type used exclusively by customer service representatives. A search query that uses that property or a term associated with that property will include search results for all items containing any of the crawled properties mapped to the Customer service representative ID managed property.

Each major business process identified in the information architecture will have a set of associated file types or business data applications that can be used to identify likely managed properties.

Note that although many concepts in the information architecture aren't represented by properties, those concepts are useful during site structure planning and the implementation of other search features. The information architecture can identify managed properties that you overlooked, but just because a concept is listed in the information architecture doesn't mean that there is or should be a managed property for that concept.

Plan for business data properties

As part of business data search planning, SSP administrators must map the properties of business applications to managed properties. Those properties must be selected as managed properties for business data for an application to appear in search results. The customer service example described previously illustrates mapping business data properties to managed properties used by search. For more information about business data planning, see Plan for business data search.

Worksheet action
Record your decisions about crawled and managed properties in the tables in the "Plan managed properties" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Use managed properties in search scopes

Each managed property can be exposed as a property for search scope rules. For more information about planning search scopes, see the "Plan search scopes" section earlier in this article.

Plan to integrate properties for new file types

Office SharePoint Server 2007 uses property categories to group crawled properties based on the properties that are discovered when the documents are crawled.

For information about property categories associated with file types, see Managing Metadata (https://go.microsoft.com/fwlink/?LinkID=81062). For more information about crawling content, see Plan to crawl content (Office SharePoint Server).

Plan what users see in search results

Office SharePoint Server 2007 provides several settings that enable SSP and site collection administrators to control what users see in search results pages. Although you can control the search results in numerous different ways, before deployment we recommend that you:

• Plan for keywords, best bets, and synonyms.

• Plan what sites are most and least relevant to control how close they appear to the top of search results.

• Plan whether to use federated locations and federation Web Parts. This feature requires the Infrastructure Update for Microsoft Office Servers. For more information, see Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007).

• Plan the appearance of links.

• Plan whether users can use search-based alerts.

Plan keywords, best bets, and synonyms

Keywords, sometimes called keyword phrases, are the words that users type into a search box when constructing a query. When users perform a simple keyword search, for example entering the word "widget" in the search box and clicking the Go Search button, Office SharePoint Server 2007 displays the search results of all content in the selected scope that contains that keyword.

Office SharePoint Server 2007 enables site collection administrators to create an entity called a keyword that is directly related to keyword phrases of the same name that are in the index. A site collection administrator can create a keyword using one or more words. For example, a keyword can be a single word, such as "OOF", or a group of words that must be typed in a particular order, such as "out of office".

In addition to the name of the keyword, also called the keyword phrase, site collection administrators can create keywords that are composed of one or more of the following options:

• A definition of the keyword that appears in search results

• One or more synonyms

• One or more best bets, which are the URLs that SSP administrators specify as being highly relevant for a particular keyword.

Keywords enable site collection administrators to improve the relevance of end user queries. The search results for any site collection can be modified to promote specific content so that it appears more prominently in response to queries that use particular search terms. Although keywords are planned, implemented, and managed at the site collection level, it is a good idea to make your planning and implementation consistent throughout your organization.

Keyword definitions are a good way to provide easy access to information about high-priority concepts in each site collection. For each concept, site collection administrators can create a keyword so that the definition of the keyword appears in the Search Best Bets Web Part next to the search results. For example, a sales portal devoted to selling a particular line of products might provide definitions for the major items in the product line. These definitions can be used to help sales associates understand their products better, or the definitions can be displayed in search results on a public-facing portal site for customers.

Keyword example

A site collection administrator knows that end users are having difficulty finding the calendar that is used to track when team members are out of the office. Users report that when they search for the calendar, their queries produce several pages of irrelevant search results, and that they give up after looking through the first few search results pages.

The site collection administrator decides to create a keyword named "oof" containing the following items:

• Keyword definition: This is the acronym we use to mean out of office.

• Synonym: time off

• Best bet: URL to the calendar and a description for the best bet.

The site collection administrator then asks the end users to use this new keyword "oof" or its synonym "time off" when searching for the calendar.

The following figure shows an example of the default search results page that end users see when searching on the keyword "oof" from the Search Center in this scenario. Note that best bets and keyword descriptions only appear on search results pages for searches that are run using the Search Center, by default.

In the figure above, the query that the end user ran is shown (callout 1). The keyword highlighting feature also shows the keywords in the content as bold text (callout 2). The description that the site collection administrator assigned to this keyword appears in the top-right corner of the search results page, by default (callout 3). Each keyword can be associated with a definition and you can include a URL in definitions. Accordingly, it is a good idea to:

• Identify definition sources during planning.

• Include a separate step during planning to design a glossary of all definitions used by keywords in each site collection.

• Create some keywords for the sole purpose of associating the keywords with a definition.

The Best Bet (callout 4) appears directly below the keyword description, if there is one. A best bet is more than a URL. It also has a title and can optionally have a description. In this example, the site collection administrator named the best bet "Out of Office page". The description that the administrator assigned to the best bet appears directly below its name, and then the URL of the best bet appears below that.

Specific documents, sites, and people with expertise in the concept associated with a search term are common uses of best bets. It is important to consider the title and description of each best bet during content planning to increase the relevance and usability of each best bet. You can associate up to 25 best bets with each keyword in the administration user interface, and many more with the object model, but it is a good idea to not overuse best bets. Effective content planning can help you identify an appropriate number of best bets for each keyword that balances the number of search results with search relevancy.

You can use the same best bet for more than one keyword. If the best bet already exists, you can add it to any keyword without having to enter the properties for the best bet again and possibly introduce redundant best bets. You can also simultaneously change the URL and description for that best bet for all keywords that use it. This is particularly useful if you are using a test site during planning and before initial deployment.

Understanding synonyms

Synonyms are one or more words that closely relate to a particular keyword. For example, an effective synonym for the keyword "car" might be "auto", "automobile", or "SUV". These are all effective synonyms for that particular keyword because you would expect that some users that are searching for cars to type one of those words into the search box instead. Site collection administrators can define one or more synonyms for each keyword. The purpose of a synonym is to display the same keyword definition and best bet on the search results page that is displayed when using the keyword. Following the previous example, if end users run a search query using the synonym "out of office" they see the same keyword description and best bets that they see when they run the search query using the keyword "oof." The difference, however, is that they see search results for only content that contains the words "out of office" instead of content that contains the word "oof".

Synonyms are useful when several search terms are used for the same concept and content, so that search results are consolidated and not scattered across several search terms. The list that is updated when a site collection administrator creates keywords and adds synonyms is called a thesaurus. The thesaurus for Office SharePoint Server 2007 is compatible with the thesaurus for Microsoft Office SharePoint Portal Server 2003.

Use information architecture to identify keywords

You can analyze the content in your information architecture to compile a list of terms with which to create keywords that you can associate with specific and highly relevant content.

Relevant content is anything specific that you want people to see first or most prominently when they search using a specific keyword. Examples of relevant content for each major business concept or content area include:

• Documents

• Sites

• People

• Definitions

• Approved or official terms that mean the same thing, but were not included in the search query.

Associating keywords with a best bet is helpful to encourage people to view the key documents that are needed to collaborate on key business processes. For example, a business might have a special template for expense reports, and a keyword "expense report" that promotes that template to the top of search results. Without that keyword, each employee might spend several minutes asking their colleagues for the appropriate URL or browsing the company Web site. With the keyword associated with the URL to the expense report template as a best bet, employees can quickly locate the template.

Keywords for sites are helpful for identifying the location of sites for relevant information in a large organization. For example, "holidays" could be a keyword associated with a best bet that contains the URL of the human resources site that contains information about paid time off for employees. Ideally, the best bet could contain the URL of the exact page that provides company holiday information.

Keywords that help people find other people encourage collaboration between people across the organization who have important knowledge to share, or just about important people in the company. For example, you can associate a title such as "CEO" with the chief executive officer for a company, or you can make a person's My Site a best bet for a keyword relating to their organization or area of expertise, such as "chemistry department."

Security considerations for keywords

Unlike previous versions of Office SharePoint Portal Server, keywords and best bets are not affected by security permissions, and all readers on the site collection can see all best bets and keywords for that site collection that appear in search results. Users who do not have permissions to see the page to which a best bet is linked cannot go to the page. However, they can see the description of the best bet on the search results page and the URLs to the content. This could expose information that some users were not intended to see.

Keywords are meant to provide high-priority results for all users.

If you want to target content to certain users based on their permissions, you can use audiences and targeted Web Parts in the appropriate places on the site collection.

Plan keywords across your organization

It is important to plan keywords in advance to help ensure consistency of keywords across your organization. Even though keywords are implemented at the site collection level, you should ensure consistency of keywords across site collections whenever possible.

Example of good keyword planning

Contoso Corporation has two site collections, one for the sales and one for the marketing department. A different site collection administrator is assigned to each. Because users of these site collections are spending too much time finding the corporation's customer list, these two site collection administrators decide that they need to create a keyword for their site collection and associate a best bet with that keyword that links users directly to the customer list.

To ensure that end users have a consistent experience on both site collections, the two site collection administrators collaborate to decide how the keyword and best bet should be defined.

By avoiding the use of different keywords and best bets across site collections that point to the same content, you can avoid end-user confusion. For example, if the site collection administrator of the sales site collection had created a keyword named "super list" and the site collection administrators of the marketing site collection had created a keyword named "master list", end users who use both site collections would become confused when their keyword searches do not consistently display the best bet they expect to see on the search results page. That is, an employee who primarily uses the sales site collection is accustomed to searching using the keyword "super list" and would expect it to work from either site collection.

In small organizations, the content planning team is likely to be small and organized around a single site collection, and planning for keywords might be organized by only one or two people. In large organizations, on the other hand, a larger planning team can be helpful. You should include business planners and administrators at each level to make sure all business needs are addressed.

Best bets appear in search results even if the content hasn't been crawled. This is another reason to plan keywords during initial deployment, so that high-priority content can be available in the early stages of a deployment before all content sources have been crawled. In rare cases where content cannot be crawled because search is missing a relevant IFilter or for any other technical reason, you can use best bets to make the content easier to find even though it hasn't been crawled.

Key people at each level of the organization plan keywords for their site collections. Those people use the same overall content plan, adapted for the content on the site collections that they are planning. When planning keywords, which starts before deployment and continues in waves after deployment, each set of content planners can communicate with each other to keep consistency in the overall plan.

Not all keywords will be planned before deployment. The role of your content planning teams is to identify the high-priority concepts that are most relevant to search queries in your organization, so that search queries are relevant to users from the first day of your deployment. The planning team can identify a contact person for each keyword who may or may not be someone on the planning team. After deployment, site collection administrators can expand the keyword list after identifying common search terms in the query logs.

In the planning phase, keyword list managers should consider how keywords match to queries. Keywords must match the complete string of search terms exactly, and must not use special syntax such as a plus sign (+) and a minus sign (-) when searching for content in lists. This prevents the return of multiple lists of keywords for the same search query, which streamlines search results.

Plan keyword management

The details of keyword management are mostly relevant to the daily operations of your site collections, but there are some aspects of administration that are worth considering when planning your deployment. Specifically the optional contact and publishing properties that site collection administrators can assign to properties.

In addition to the properties listed in the "Plan keywords, best bets, and synonyms" section earlier in this article, each has the following optional properties:

• Start, end (expiration), and review dates

• Contact

Keywords can be required to go through approval before they affect search results, and can also be set to start or expire after a certain amount of time. The high-priority keywords identified during initial planning are unlikely to be temporary, except for content that is relevant to people using a site collection during the initial deployment.

The contact for each keyword is the person who should be contacted when a keyword expires, if it is set to expire. Content planners for each site collection should consider who is going to be managing keywords after the initial deployment, and include at least some of those people in the planning process at the site collection level.

However, part of the planning process is anticipating who will make decisions about keywords in the future. Making those decisions during the planning process can improve the transition to regular operations of the site collection, and promote consistent and efficient use of keywords in the future.

By using the object model, you can also import and export keywords between site collections as an Excel spreadsheet, so if some best bets apply to other site collections, you can plan once and deploy on all relevant site collections. This also allows keyword managers for a site collection at the divisional or project level to suggest best bets for a central site collection in a shared services environment.

For more information about managing keywords, see the Operations Guide for Office SharePoint Server 2007.

Worksheet action
Record your decisions about keywords in the "Keywords" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Plan the relevance of search results

The greater the body of content that is being searched over, the more likely it is that several pages of search results will be displayed for a particular query. This is especially true when basic keyword queries instead of advanced queries are used. To facilitate a positive end-user experience, ensure that links to the most relevant content are displayed as early as possible on the search results pages.

Office SharePoint Server 2007 enables SSP administrators to assign indexed Web pages relevance settings. Each relevance setting, which is associated with a particular Web page, determines how close to the top of the search results page the link to a particular page appears. Pages that are assigned a relevance setting are known as authoritative pages.

Authoritative page settings are one factor in prioritizing search results. For more information about search relevance, see Enterprise Search Relevance Architecture Overview (https://go.microsoft.com/fwlink/?LinkId=93736).

Authoritative page settings are configured at the SSP level and apply to all queries made using that SSP. SSP administrators can assign sites to one of four authoritative page levels:

• Most authoritative

• Second-level authoritative

• Third-level authoritative

• Sites to demote

Web pages are weighted based on how authoritative they are, with each level receiving proportionate relevance weighting. By default, all top-level pages for Web applications are automatically added as most authoritative. You can move these pages to other authoritative page levels or remove them from authoritative page settings completely.

Sites that are not assigned an authoritative page ranking are weighted based on their click distance from an authoritative site. Click distance refers to the number of links between a content item and an authoritative page linking to the content item. For more information, see the "Click Distance" section Enterprise Search Relevance Architecture Overview (https://go.microsoft.com/fwlink/?LinkId=93736).

Sites that are assigned the Sites to demote setting will typically appear towards the end of the search results after all other relevance weighting factors have been considered.

This means that they often appear on the search results page after pages that are not even specified as an authoritative page. We recommend that you use this setting for sites that contain less relevant information (for example, an archive site).

When planning authoritative page settings, consider the purpose of each site, and review its subsites. Group authoritative sites into the three levels by importance and group the sites that are not likely to be relevant as sites to demote.

Good practices to use when planning authoritative page settings include:

• SharePoint sites and business applications central to high-priority business processes will typically be most authoritative.

• Sites that encourage collaboration or action are likely to be more authoritative than sites that are merely informative.

• Sites that are informative but not central to high-priority business processes or used for collaboration are likely to be in the second or third level of authoritative sites.

• External sites will typically be less authoritative, because your organization cannot control the content on those sites.

• You don't need to assign an authoritative page setting to every site. It is a good idea to select relevance for a small number of sites that you know are most authoritative or less relevant, and adjust the authoritative page settings during normal operations based on feedback from users and information in the query logs.

Worksheet action
Record your decisions about authoritative pages in the "Authoritative pages" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Plan whether to use federated locations and federation Web Parts

Federation, a new feature that was first introduced in Search Server 2008 and is available in Office SharePoint Server 2007 by installing the Infrastructure Update for Microsoft Office Servers, can be planned with the rest of the end-user search experience. Federation enables end users to issue a query that searches multiple sources and combines results into a single search results page. These sources can include:

• Your company's enterprise content repositories

• Internet search engines or subscriptions services used by your company

• Enterprise documents indexed by Office SharePoint Server 2007 in other divisions or world regions

When the end user issues a query, Office SharePoint Server 2007 formats and renders the results alongside your indexed results by using new federation Web Parts.

When you plan the experience you want for your users when they search federated locations, try to target the searching needs and habits of users in your company. Ask yourself these questions: What content do your users need to find most to be productive? What queries are they currently using? Target your federated locations to solve the key information problems in your company.

When using federation it is tempting to add many federated locations to satisfy all the possible needs of your users. Unfortunately, this leads many users to disregard federated results as clutter.

To help ensure that federated results target useful answers to queries, federated locations can match specific query formats with trigger rules. When you create a trigger rule for a federated location, the Web Part that is associated with that location displays results only for queries that match the pattern or prefix that you specify.

For example, let's say that you work at a company called Contoso, where employees manufacture a product called a widget. Employees need to find these widgets many times a day by using a ten-digit widget ID. Widgets are stored in a database that cannot be crawled by Office SharePoint Server 2007. To enable Contoso employees to search for widgets, you build a federation connector that searches the widget database. However, displaying widget information for every query would likely frustrate your users. So, you create a federated location trigger by using a pattern that recognizes ten-digit queries. Now, when users search for widget IDs, they get a top federated result from the widget database.

For more information about using triggers and trigger rules, see Work with triggers and query templates (Office SharePoint Server).

You can add and configure federated results on the search results page with either a Federated Results Web Part or a Top Federated Results Web Part. By default, the search results page contains two Federated Search Results Web Parts and one Top Federated Results Web Part. You set the federated location and its properties in the Web Parts on the search results page.

For more information about federation, see Federating search results from other locations (Office SharePoint Server).

Plan the appearance of links

SSP administrators can use server name mappings to change how particular URLs or ranges of URLs are displayed in search results. Server name mappings are set at the SSP level for all content that is crawled by that SSP, and are applied whenever a full crawl of the affected content sources is performed. You might want to use server name mappings in the following scenarios:

• You want to prevent access problems and possible security vulnerabilities caused by links that show the local addresses on the server. For example, depending on how content is crawled, a URL might display a local path on the server.

• You want to obscure complex URLs in search results, so you replace them with a more concise name on the server.

• For security reasons, you want to hide the name of the original source of the content such as the server or share name.

Use server name mappings only when you have one of the display problems described in the previous list. In most cases, planning for server name mappings prior to the initial deployment will be minimal.

Worksheet action
Record your decisions about authoritative pages in the "Authoritative pages" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Plan search-based alerts

An SSP administrator can decide whether search-based alerts will be activated for a particular SSP. If search-based alerts are activated and the server is configured to send e-mail, end users can click the Alert Me link at the top of search results pages and specify what kind of changes they want to be alerted to and how frequently they want to receive an alert in e-mail. Note that when you allow search-based alerts, your system uses additional resources on mail servers and increases the load on query servers because queries for each search-based alert run every time a search-based alert is processed. When planning the initial deployment, consider the resources available for alerts and the likelihood that people using your sites will use alerts productively. Search-based alerts are activated, by default.

During operations, search-based alerts are automatically disabled whenever the entire content index is reset in order to avoid sending notifications for all search-based alerts. Administrators then have to re-enable search-based alerts.

Worksheet action
Record your decisions about search-based alerts in the "Search-based alerts" section of the End-user search experience worksheet (https://go.microsoft.com/fwlink/?LinkId=81039).

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Plan Sites and Features, Part 1

See the full list of available books at Downloadable content for Office SharePoint Server 2007.