Note: This article has done its job, and will be retiring soon. To prevent "Page not found" woes, we're removing links we know about. If you've created links to this page, please remove them, and together we'll keep the web connected.
In this article
Administrators can improve the relevance and presentation of search results by planning the right configuration of administration settings that affect search queries. While the effectiveness of search queries are constantly evaluated during regular operations of any deployment of SharePoint Products and Technologies, good planning before the initial deployment can create effective search queries from the start and help to reduce future administration costs. Administrators for Shared Services Providers (SSPs) can plan managed properties for search to use across the SSP, relevance settings for specific sites, and the search scopes that users in sites across the SSP use to narrow the content included in each search query. They can also change the presentation of results through server name mappings, and customization of search center sites, the search box, and other search presentation features. Site collection administrators can supplement these plans by planning site-specific search scopes and keywords.
Plan search scopes
Search scopes are filters applied to search results to narrow the results of a search based on subsets of content selected for scopes by administrators. Search scopes enable people using Microsoft Office SharePoint Server 2007 to make their searches more relevant by searching within certain subsets of content within a site collection.
Shared search scopes are created at the SSP level. Those search scopes are designed to be relevant across all site collections in the same SSP, and are shared with all site collections.
Site collection administrators decide which shared scopes to use and how to display them, and can also create site collection search scopes that are only used within the site collection.
When planning to use search scopes, you look at your information architecture to identify broad content sets that people are likely to want to search. Some of these sets will span the information architecture of site collections, and some will span subsets of information within site collections. You decide whether to implement shared search scopes or site collection search scopes based on where content falls within the information architecture.
Plan shared scopes
The SSP administrator manages shared search scopes for across all sites that are using the same shared services. The SSP administrator can also manage search scopes for site collections.
SSP administrators can perform the following tasks:
Creating and editing shared search scopes.
Deleting search scopes.
Managing and scheduling compilations of search scopes.
Shared scopes are search scopes that are visible and available for use by administrators for all site collections that are using the same set of shared services. Shared search scopes should be implemented for bodies of content based on concepts in the information architecture, site structure, and content needs planning that are relevant for everyone in the SSP. Content that is only relevant within certain site collections should be left for search scope planning at the site collection level.
For example, a large organization might create a shared scope for content relating to human resources, because human resources is a large division with content relevant to all employees on several SharePoint sites and line of business applications identified during content and site structure planning. The site collection administrator of the human resources site can use that shared scope, and also create additional scopes for the site collection for company policies and new hire information because those are core concepts identified as relevant for the site collection. Those site collection scopes do not make sense as shared scopes, because people searching in other sites are unlikely to want scopes that are so specific.
SSP administrators decide whether the shared scopes they create must appear in display groups created by portal site administrators, such as the search box drop-down list and the advanced search page. Shared search scopes that are not required can be added to display groups at the discretion of the site collection administrators.
The following shared search scopes are created by default for each SSP:
Plan search scopes for site collections
For each site collection, a site collection administrator can do the following tasks that are related to search scopes:
Use shared scopes created by the SSP administrator.
Copy and modify a shared scope to use as a scope for the site collection.
Create, edit, and delete search scopes for the site collection.
Choose how to display search scopes.
Monitor the status of search scopes.
Site collection administrators cannot create or add matching rules to shared scopes provided by the SSP administrator, though they can duplicate a shared scope and modify the copy. They can add new matching rules for site collection scopes.
SSP administrators can perform all of these administrative tasks that site collection administrators can perform.
During planning, each site collection administrator will want to create search scopes based on the information architecture within the site. By default, each site collection has access to the People and All Sites shared scopes. Administrators can add search scopes by selecting shared scopes that are useful for people using their site collection, and then supplementing those scopes by creating search scopes for the site collection.
Site collection administrators can use display groups to organize groups of search scopes by how they appear on the site. By default, Office SharePoint Server 2007 provides display groups for the search box drop-down menu and the advanced search page.
Plan search scope rules
Search scope rules are added to search scopes to define the extent of each scope.
Rules are based upon the properties, locations, and content sources of content. Each rule tests all content for a single property, location, or content source. Each rule affects search results for the search scopes that contain it in one of three ways:
Include Items matching this rule appear in search results unless another rule removes them. This is equivalent to the OR logical operator.
Require Items matching other rules must also match this rule to appear in search results. This is equivalent to the AND logical operator.
Exclude Items matching this rule are excluded from search results even if they match other rules. This is equivalent to the AND NOT logical operator.
Search scopes contain one or more rules and content must match all rules in the currently selected search scope to be included in search results.
Using rules based on managed properties
Search scope rules can be based on a specific value for a single managed property in the search schema. Each item of content is tested against that specific value and included or excluded based on the rule. Rules based on properties can only be tested against the Is exactly operator and not against other hypothetical operators such as Contains.
For example, a sales portal site can create site collection search scopes for each of its sales offices by using the Sales Office managed property and setting the value for the rule in each scope to the value for the relevant office. Because this managed property is based on data from a sales tracking application, the search results will include only business data search results for the sales office for the selected scope.
When you plan the managed properties for your SSP, it is helpful to think about search scopes at the same time. To create a search scope for a certain set of content, you must ensure that there are properties of that content that can be included in matching rules.
Each managed property in the SSP can be made available as a property for search scope rules, for both shared scopes and site collection scopes. Only the managed properties that specifically have been made available for search scopes can be used in search scope rules.
Using rules based on location
You can create matching rules based on the location of content. Several usage scenarios require rules of this kind, including:
Searching over a group of document libraries.
Searching within a set of folders in a single large document repository, as when searching a company archive.
Searching for content on external sites for a particular subject.
Searching for content in other servers in your organization.
Each 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 search scope, you would add one or more matching rules until all relevant locations are included in the search scope. The information architecture and site structure planning will both provide guidance in deciding which locations to include in each search scope.
Using rules based on content sources
Search scopes can also contain rules based on content within specific content sources. Your content source planning will 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 indexed by that content source is something that would make sense grouped together in a search scope for people using the site collection. If so, you can add a matching rule for that content source.
Also consider if the content source can be divided up into smaller bodies of content people that people may want to search for. If so, you can combine content source matching rules with other matching rules to create a more narrow scope.
By using rules based on content sources, you can easily enable people in a central site collection for a large organization to search over content on site collections for smaller projects or divisions. To do this, SSP administrators add a matching rule for the relevant content source. That search scope can be shared so that people using any site collection in an SSP can potentially search over content on any other site collection in the SSP. For example, this is useful is a division-wide site collection with a search box menu for the human resources site collection.
Using multiple rules
Search scopes will often be simple scopes based on a single matching rule. But there are many good reasons to use search scopes with multiple rules. What these reasons have in common is that they seek to create search scopes based around a specific theme or conceptually-related set of content. To do this, you must include several locations, several properties, or a combination of locations and properties that are conceptually related.
Rather than just creating basic one-rule search scopes for every conceivable property or location that might eventually be relevant, it is a better idea to think in terms of broad concepts and use those to create a shorter list of complex search scopes for each site collection. Use complex scopes with multiple rules targeted at specific document libraries, file shares, mail servers, data sources, based on the evaluation of your information architecture.
Using exclusion rules
Matching rules that exclude content are created and selected just like any other rules used in search scopes. However, you might want to consider their implementation as a separate step. Reasons to exclude content from search results can differ substantially from the reasons to include content.
The All sites search scope can be used as a starting point to include all site collection content. Then you can add matching rules that exclude content to create search scopes that are broad but do not include a certain set of search results. It is sometimes easier to use an All sites matching rule with exclusion rules that create a complex search scope containing rules for every subset of content on the site.
Example of search scope planning
Contoso Corporation has an IT services division, a customer service division, and a sales and marketing division. Each division has its own site collection, and there's also a central portal site collection for company news and human resources information. The SSP administrator plans to operate the search service on a single SSP for the entire company. By default, searches in the organization will include content from any division, because that's the default search scope. Because the content for each division is distinct, content will be crawled in three separate content sources so that IT, customer service, and sales and marketing information can all be updated on different schedules.
Jacky Chen, the SSP administrator, plans to create separate content sources for each division, based on rules including those content sources. She also plans to create a content source for the human resources business application that tracks information for all employees, using a rule based on a business data content source. Each site collection administrator decides to include the default shared scope for all content in the organization, but none of them plan to use the human resources scope, even though it's a shared scope. That option will only be available from the search drop-down menu in the central portal site collection. Each site collection administrator also plans to add site collection scopes for important sets of content within their site collections. For example, the site collection administrator for the sales and marketing site collection plans to create search scopes for content related to each product line, based on the managed properties of business data, marketing documents, and other content, and the location of related team sites and document libraries. All of these content sources, locations, and properties are listed on the search features planning worksheet for the relevant search scope.
Search scopes of both types are defined by one or more rules concerning properties and document locations. Content can be either included or excluded from search scopes by these rules.
Plan relevance settings
Relevance settings prioritize Web sites and other locations in content sources so that results from those sites are more or less likely to appear at the top of search results. Relevance 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 for search managed by the SSP administrator, or the automatic weighting applied to content by the search technology. SSP administrators apply relevance settings to all queries made using the SSP, and can refresh relevance settings without re-crawling content sources. SSP administrators can place sites in one of four relevance levels:
Three authoritative levels: Most authoritative, second-level authoritative, and third-level authoritative.
One level of less relevant sites.
Authoritative 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 added as most authoritative. You can move these pages to other relevance levels or remove them from relevance settings completely. You can also add sites in each of the levels.
The less relevant sites are demoted to lower priority with the same amount of weighting as given to third-level authoritative sites.
When planning relevance settings, consider the purpose of each site, and review its subsites and the sites crawled by content sources. Group authoritative sites into three levels by importance, record the planned relevance settings for each of those sites in the search features planning worksheet, and mark all other sites as less relevant.
Good practices to use when planning relevance 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.
Secondary business processes 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 group the relevance of 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 relevance settings during normal operations based on feedback from users and information in the query logs and crawl logs.
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.
Plan properties for search
In Office SharePoint Server 2007, the schema that you use to organize content strongly influences the effectiveness of search features in your site collections. To effectively deploy Office SharePoint Server 2007. start by understanding the information architecture of your organization, and then apply that understanding to plan managed properties for finding site collection content and business data regardless of file type, and to create search scopes.
The enterprise search functionality of Office SharePoint Server 2007 uses a combination of text and properties about each document to prioritize search results. Good management of properties for search is important for providing relevant search queries. The properties of content that are used to process search queries, apply search scopes, and personalize content are sometimes called the search schema. By thinking of search properties as part of an organized schema, you can plan to use properties accross the Shared Services Provider (SSP) to create a consistent search experience across the content in your organization.
When you crawl content, you crawl the properties associated with that content. Examples of crawled properties include the metadata of Office client applications, Web pages, and documents from other applications used by your organization, and the data stored in databases and line of business applications used by your organization.
In previous versions of Microsoft SharePoint Portal Server, all of these properties were used when searching for people, documents, or sites. 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 using managed properties. Managed properties are a set of properties that SSP administrators create because those properties are relevant for search results. SSP administrators map crawled properties to managed properties that are used by search queries to prioritize search results across the SSP.
Site collection administrators cannot add or view the list of managed properties, but those managed properties can be used in some administration tasks for the site collection, such as search scopes administration.
You can make the content on your site easier to find by carefully planning your schema and how you implement managed properties,
Plan managed properties based on the information architecture
As part of site planning, you analyze the content and key business processes of your organization, and organize this content and these processes into a taxonomy called an information architecture. There are many ways to do this, and the details of an information architecture and the amount of time that is required to prepare it can vary widely from organization to organization. One practical way to identify key concepts 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 an 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 information architecture can be useful for planning managed properties. Every concept in your information architecture can potentially be represented by a managed property. If you identify managed properties for all key concepts in the information architecture, you will have a complete schema of managed properties that accurately represents the most important content and business processes in your organization. The key to creating a useful schema is to determine the most important concepts and find properties in your content that you can add to the schema that enable you to find relevant content when searching. Be precise when mapping crawled properties to managed properties to maintain performance and increase relevance. Mapping more properties increases the size of content databases, and reduces performance accordingly, so it's a good idea to map properties only when you are highly confident of the relevance of the mapping.
You can represent these concepts in other ways during implementation as well. 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, 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. One thing to realize is that 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. A good practice is to map properties that seem to be related, and then perform relevant searches to see if the expected results appear.
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. Those properties include but are not limited to:
Last Modified Date
Eliminate redundant and duplicate properties by using property mapping
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, or Team or Division properties for people. Adding each Author property as a separate managed property doesn't make sense, because it adds additional managed properties to the database without increasing relevance. 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. 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. Imprecise mappings can actually reduce the relevance of search results. As always, 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
Other crawled properties might clearly map to concepts in the information architecture that are not already captured by existing managed properties. For each concept in your information architecture, ask yourself if there's a crawled property that represents this concept that can be made into a managed property. For every crawled property, ask if there's a place for it in the information architecture. If so, update the information architecture and make the property a managed property.
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 may include customers, customer service representatives, and customer service regions. There's a line of business application that 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 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 a managed property for that concept.
Plan for business data properties in the schema
As part of business data search planning, SSP administrators must map the properties of business applications to properties in the schema. 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 is an example of mapping business data properties to managed properties used by search.
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 section on search scopes in this article.
Plan to integrate properties for new file types using filters
Office SharePoint Server 2007 uses property categories to crawl properties by documents within each category. Property categories include the protocol handler and filter used by search when it indexes content. Before you crawl content, you want to associate it with the property categories that will most effectively find the crawled properties you need before you create managed properties.
By default, Office SharePoint Server 2007 provides the following property categories:
If you add content that uses different filters or protocol handlers, you can create a new property category. As part of your initial planning process, you should identify what content needs new filters and protocol handlers. This might require custom code, though some filters and protocol handlers will be available.
Plan for search query usage data
You can use the usage data for search queries during regular operations to see the queries that are commonly used in your organization, so that you can plan to implement features to increase the effectiveness and relevance of search results. On the Shared Services Administration page, in the Portal Usage Reporting section, click Usage reporting. Search query logging is one of two settings on the page. You can use the usage data during a test deployment to prioritize the search features to deploy during the initial deployment. You can also use the planning worksheets developed prior to the initial deployment to check actual search queries against your plan. This enables you to evaluate which search queries are effective and which should be changed, as well as implementing previously planned search features that you didn't use as part of the initial deployment.
Plan server name mappings
Server name mappings change how the location URL is displayed for each item in search results. Server name mappings are set at the SSP level for all content sources crawled by that SSP, 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 caused by links that refer to local addresses by mapping them to addresses 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.
Use server name mappings only when you have known access or display problems. For each content source you plan, consider if its start addresses contain local URLs, complex URLs that you would like to simplify for your users, or point to locations that you want to help keep more secure. In most cases, planning for server name mappings prior to the initial deployment will be minimal.
Plan search-based alerts
You can decide whether search-based alerts will be enabled for users on each SSP. People using search-based alerts can ask to be alerted when the results of their saved searches have changed. The drawback with enabling search-based alerts is that search-based alerts use resources of mail servers, and they also impact the load on query servers because the 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.
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.
Keywords are metadata that are used to prioritize content during search queries to display high-relevance content more prominently in search results. Each keyword is represented by a keyword phrase composed of one or more words, a list of synonymous search terms, and a definition of the term. Searches using that exact term or one of the synonyms promote specific content pre-selected by site collection administrators so that they show up at the top of search results. The results associated with each keyword are called Best Bets. Keywords are used to highlight or promote search results that the administrator has determined are more relevant for users of each site collection. Keywords appear in a high-confidence Web Part next to search results, and users can click the keyword to view the full definition, synonyms, and Best Bets.
Keywords are typically updated and expanded for greater relevance as part of ongoing operations. However, to promote collaboration for key business content and data related to key business processes, it can be helpful to plan a small set of high-priority keywords before beginning deployment. .
Use information architecture to identify keywords
You can use the information architecture created by your content planning teams to identify high-priority content to implement as keywords. Your information architecture is already a hierarchical list of terms. It is fairly straightforward to take some of those terms and quickly associate them 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 search term. Examples of relevant content for each major business concept or content area include:
Approved or official terms that mean the same thing, but were not included in the search terms used in the search query.
Keywords for documents are helpful to encourage people to view the key documents needed to collaborate on key business processes. For example, a business may have a special template for expense reports, and a keyword "expense reports" 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, they can quickly locate the template and enter their expenses.
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 for the human resources site about paid time off for employees. The keyword helps employees quickly find out when a holiday is so they can plan their work schedules accordingly.
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, a title such as "CEO" could be a keyword associated with the chief executive officer for a company, or a person could be a Best Bet for a keyword relating to their organization or area of expertise, such as "chemistry department."
Keywords based on definitions are a good idea for high-priority concepts in each site collection. For each key idea, site collection administrators can create a keyword so that the definition of the keyword appears near the top of 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.
Use properties of keywords
Keywords are organized into keyword lists that hold lists of keyword phrases. The following properties of keywords help to highlight content:
Keyword phrase The keyword phrase is the entire text string used in a search query, and it identifies the keyword. When users type in the keyword phrase, the search results for the keyword appear. When the results appear, the keyword phrase appears at the top of the search results.
Synonyms Each keyword can have one or more terms identified as synonyms, and the same search results appear for a synonym as appear for the keyword phrase. The keyword phrase displays at the top of search results from any query using one of the synonymous terms. This is useful when several search terms are used for the same underlying concept and content, so that search results are consolidated and not scattered across several search terms. The keyword list including all synonyms is known as a thesaurus. The thesaurus for Microsoft Office SharePoint Server 2007 is compatible with the thesaurus for SharePoint Portal Server 2003.
Definition Each keyword can have one or more definitions, and search results for keywords display the definitions next to the keyword phrase, before any other search results. You can also include the title or the URL of the source for the definition, so it's a good idea to identify definition sources during planning. You might even have a separate step during planning to design a glossary of all definitions used by keywords in each site collection.
Best Bet Best Bets for a keyword are promoted to the top of search results for queries using that search term, just below the definition for the keyword if there is one. Specific documents, sites, and people with expertise in the concept associated with a search term are common examples of Best Bets. A Best Bet is more than a URL. 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 every keyword in the administration user interface, and many more with the object model, but it is a good idea to not overuse Best Bets. Good content planning with an organized information architecture should help you identify an appropriate number of Best Bets for each keyword that balances number of results with search relevancy.
Note that unlike in previous versions of SharePoint Portal Server, keywords 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. keywords are meant to be 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.
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. By using a single information architecture to identify your key concepts, associating certain content with certain site collections, and then planning keywords for the information architecture relevant within each site collection, you avoid duplication and confusion of keywords and increase the relevance of search results across your organization.
Keyword Best Bets appear in search results even if the content hasn't been crawled, as long as the person viewing the results has access to the content. 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 keyword Best Bets to make the content easier to find even though it hasn't been crawled.
As with other parts of the planning process, you will have key people at each level of the organization that plan keywords for their site collections. Those people will use the same overall content plan, adapted for the content on the site collections that they are planning. At each stage of the process, which happens in waves over time, each set of content planners can communicate with each other to keep consistency in the overall plan.
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, you want to include business planners and administrators at each level to make sure all business needs are addressed, so somewhat larger planning teams are often helpful.
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. Then they can identify contacts for each keyword who may or may not be people 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 -. This prevents the return of multiple lists of keywords for the same search query, which streamlines search results. Because of this, you must carefully consider synonyms so that keywords actually match to the relevant content without matching unrelated content.
You must also consider that keywords match across search queries for each site collection, and cannot be excluded by search scopes that narrow the search results. This can affect planning for search scopes, so most content planners and administrators will plan implementation of these features as part of the same process.
The more planning you do before deployment, the less management will be needed during day to day operations.
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 during planning.
Each search keyword has the following additional properties:
Start, review, and expiration dates
The contact for each keyword is the person who should be contacted when a keyword expires. A contact may not be directly responsible for managing keywords. Content planners for each site collection should consider who is going to be managing keywords after initial deployment, and include at least some of those people in the planning process at the site collection level.
The life cycle of keywords is also important to consider. 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. 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.
Because the URLs for keywords are associated with the Best Bet, 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 properties again and possibly introduce redundant Best Bets. You can also change the URL for that Best Bet for all keywords that use it at the same time. This allows for easy migration of your content to a new site. This is particularly useful if you are using a test site during planning and before initial deployment.
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.
Use the search planning worksheets
The search features planning sheet has columns for each of the major search administration tasks that you plan for initial deployment. For each search scope you plan during initial deployment, record the relevant rules, listing each property, location, and content source used by any of the matching rules for search scopes. Ensure that each content source is listed in the content source section of the search features planning worksheet, that each location used by a rule is included in the site structure planning worksheet, and that every property listed is included in the search properties planning worksheet.
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. The search properties planning worksheet includes a list of managed properties for each SSP. Where the crawled properties are known during planning, those properties are listed in the column next to each managed property. 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 Word documents or Excel spreadsheets. 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, and record the mappings on the planning worksheet. A worksheet that effectively reflects good planning of search properties is a valuable reference when you begin deploying search.
You can record the list of keywords and the keyword phrases, synonyms, descriptions and description sources, and Best Bets for that keyword, in the appropriate section of the search features planning worksheet. This worksheet can then be used during initial deployment and configuration so that your planning decisions are properly implemented, and so you can prioritize between different plans. Any keywords you don't implement during initial deployment will still be recorded on the worksheet and can be deployed during part of ongoing operations.