Plan the end-user search experience (Search Server 2008)

Applies To: Microsoft Search Server 2008

 

Topic Last Modified: 2008-04-02

In this section:

• 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 the planning is to create a search experience that enables users to quickly find the information they need. This article contains information that can help search services administrators and site collection administrators optimize the end-user search experience.

The first section of this article:

• Describes the search user interface for performing search queries.

• Discusses 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.

• Discusses 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 discusses search results pages and the features that administrators can control that affect what users see in search results.

The second section of this article:

• Describes 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.

• Discusses 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.

• Describes how to control the links that appear in search results.

• Discusses how to plan for search-based alerts.

The abilities described in this article enable administrators to control many of the features of the end-user search experience. Although we recommend that you regularly evaluate the effectiveness of search queries, good planning prior to initial deployment can help create effective search queries from the start and may 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.

The search user interface

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 and list levels as well as on the Search Center. The Search Center itself is a site collection.

The following sections describe the 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 enter their search queries and then click the Go Search icon (callout 3) to run their query.

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 (callout 1) next to the search box specifies the body of information in the content index that the query will be run against. Search scopes, also referred to as scopes, are filters that are applied to search results to narrow (that is, filter) the items that are displayed on the search page based on whether those items are included in the scope. This enables users to perform queries against subsets of content in the content index, which improves the relevance of their search results.

By default, the site-level search box uses the This Site scope. This means that queries are run against all content that is associated with the current site and all of its subsites.

List-level search user interface

The search user interface at the list level looks and functions the same as the site-level search user interface, except that an additional default search 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 and is set to use the This List scope, by default. However, users can select the This Site scope or a custom scope, if available.

Search Center search user interface

The Search Center provides a centralized and highly customizable user interface where users can perform search queries. The Search Center consists of a search box for entering search queries, and a link to the 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.

Similar to the search box at the site-level, the search box in the Search Center (callout 1) is a text box in which users can type their search queries. Users then click the Go Search button (callout 2) to run their query. Advanced users can click the Advanced Search link (callout 3) to use the Advanced Search page to construct queries. Information about the Advanced Search page is provided later in this article.

If Microsoft Search Server 2008 was installed using the basic install option, the Search Center template is used to create the top-level Web site. This means that the top-level site of your site collection is the Search Center.

The following table shows the scopes that are available in Search Server 2008, by default, and the levels at which they are available.

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

Plan custom scopes

This section provides information about the default scopes that can be used to filter the content included in a search query. As a search administrator, you can help identify when your organization might need to supplement the default scopes by creating custom scopes. You can use custom scopes with scope rules to group certain content in the index into individually searchable pieces of content.

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 period of time or a combination of these parameters.

You can create custom scopes at the site collection level, which makes the custom scopes available to the site collection on which they were created.

When planning search scopes, you look at your information architecture to identify broad content sets on which people are likely to search. Some of these sets will span across many sites, and some will span subsets of information within site collections.

Plan scopes for site collections

During planning, each site collection administrator will want to create scopes based on the information architecture within the site.

The following is a list of tasks related to scopes that site collection administrators can do at the site level:

• 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.

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

• Unique title.

• Description for the scope (optional).

• 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, Search Server 2008 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 or create new display groups.

• 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.

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 have to either perform separate searches in different search boxes, for example, 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. Search Server 2008 provides two display groups, by default:

• Search Dropdown   The All Sites scope is 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 site-collection-level search scopes.

This scope rule type	Is available to site-collection-level search scopes	Tests content by
Web address (https://server/site)	Yes	Location
Property Query (Author=Jane Dow)	Yes	Single property
Content Source	No	A particular content source
All Content	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, a search services 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 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 a search services 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 search services administrators have specifically made available for scopes can be used in search scopes.

  Note

  Search services 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 managed properties, 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

When you have Search Server Administrator permissions, you can create scope rules on site collection-level content sources. You might do this for several reasons:

• To create additional content sources that crawl content on a different schedule.

• To create a separate content source to crawl content on a different SharePoint Services and Technologies farm or on a file share.

• To divide the content into smaller sets with which to combine scope rules and to create a narrower scope of content.

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

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 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 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 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.

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 David Jones, they could type the following query in the search box:

negotiate author:jones

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. Search services administrators choose which managed properties they want to make available to scopes and can create additional properties to meet their organization's needs.

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. Search Service 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 properties associated with that content. Crawled properties include the metadata of content that is stored in files, and databases used by your organization. Crawled properties can represent different kinds of information, such as author, title, and e-mail address.

Search Server 2008 enables search services 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. Search services 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.

• Search services administrators 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. Search services 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, the managed property has to be made available to scopes, 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.

Administrators planning the initial deployment of Search Server 2008 should record the initial set of managed properties planned for the search service.

Many of these crawled properties can be found by looking at 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 Search Server 2008, 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 database, and reduces performance accordingly, so it's a good idea to map properties only when you are confident that the mapping is relevant.

Some concepts are used to suggest site collection structure and content within site collections. Others are used to create special terms such as keywords to highlight relevant search results.

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 Search Server 2008 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 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.

When you map properties with different data types, the data type of the managed property is used by search in most cases.

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.

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.

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 by using IFilters

Search Server 2008 uses property categories to crawl properties by documents within each category. Property categories include the protocol handler and IFilter used by search when it indexes content. Before you crawl content, you want to associate the content with the property categories that will most effectively find the crawled properties you need before you create managed properties. To register IFilters with Search Server 2008, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008.

If you want to add content to your content index that requires different IFilters or protocol handlers, you can programmatically create a new property category for that content. As part of your initial planning process, you should identify what content needs new IFilters and protocol handlers. This might require custom code, though some IFilters and protocol handlers are provided.

For information about property categories, see Manage metadata property mappings (Search Server 2008). For more information about crawling content, see Plan to crawl content (Search Server 2008).

Plan what users see in search results

Search Server 2008 provides several settings that enable search services and site collection administrators to control what users see in search results pages. Although you can control the search results in numerous different ways, during 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.

• Plan the appearance of links.

• Plan whether users can use search-based alerts.

Plan keywords and Best Bets

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, Search Server 2008 displays the search results of all content in the selected scope that contains that keyword.

Search Server 2008 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 search services 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 sure your planning and implementation is 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 pages.

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

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. They also have 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

A synonym is 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 Search Server 2008 is compatible with the thesaurus for Microsoft Office SharePoint Portal Server 2003.

Use information architecture to identify keywords

You can use the information architecture created by your content planning teams to identify high-priority content to associate with keywords. Because your information architecture contains a list of terms, you can quickly use some of those terms 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.

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 poor keyword planning

A site collection administrator creates a keyword named "super list" on the marketing site collection and creates a best bet for that keyword that contains a URL to company's customer list. Another site collection administrator creates a keyword named "Master list" on the sales site collection and creates a best bet for that keyword that contains a URL to the same customer list.

Users that use the both site collections will become confused when their keyword search does not consistently display the Best Bet they expect to see on the search results page. For example, an employee that primarily uses the marketing 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 after deployment in waves over time, 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 + and - 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.

Each keyword 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.

For more information about managing keywords, see Manage settings to improve search results (Search Server 2008).

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.

Search Server 2008 enables search services administrators to assign indexed Web pages relevance settings. Each relevance setting, which is associated with a particular Web page, determines how early on 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, and do not outweigh all other factors such as keywords managed by site collection administrators, managed properties that are managed by the search services administrator, or the automatic weighting applied to content by the search technology.

Authoritative page settings are configured at the Search Administration level and search services 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 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 irrelevant 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 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 and crawl logs.

Plan whether to use federated locations and federation Web Parts

Federation, a new feature in Search Server 2008, 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 Search Server 2008 in other divisions or world regions

When the end user issues a query, Search Server 2008 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 Search Server 2008. 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 in the Search Server 2008 Help.

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 in the Search Server 2008 Help.

Plan the appearance of links

Search services 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 Search Administration level for all content that is crawled by that Search Service, and are applied whenever queries are 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.

Plan search-based alerts

A search services administrator can decide whether search-based alerts will be activated for a particular Search Center. 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 content sources are reset in order to avoid sending notifications for all search-based alerts. Administrators then have to re-enable search-based alerts.