# What happens to on-site search after migration? > When you migrate off WordPress, your on-site search is rebuilt as a feature rather than carried over, because WordPress search is a database query and a static or rebuilt site does not run that query the same way, so search is reimplemented using a prebuilt search index or a hosted search service. Visitors get the same thing, a search box that returns matching pages, often faster than before. There is nothing to redirect, because WordPress search result URLs, the ?s=query addresses, are throwaway pages that should not have been indexed anyway, so you are not preserving them. The content that search looks through is your migrated pages, so as long as the content came across, search has something to index. WPBuildAI rebuilds on-site search with a fast index over your migrated content, so visitors can still search the site, while the disposable ?s= result URLs are simply left behind. Source: https://wpbuildai.com/what-happens-to-site-search-after-migration/ By lawrence-arya ยท 2026-06-13 --- When you migrate off WordPress, your on-site search is rebuilt as a feature rather than carried over, because WordPress search is a database query and a static or rebuilt site does not run that query the same way, so search is reimplemented using a prebuilt search index or a hosted search service. Visitors get the same thing, a search box that returns matching pages, often faster than before. There is nothing to redirect, because WordPress search result URLs, the ?s=query addresses, are throwaway pages that should not have been indexed anyway, so you are not preserving them. The content that search looks through is your migrated pages, so as long as the content came across, search has something to index. WPBuildAI rebuilds on-site search with a fast index over your migrated content, so visitors can still search the site, while the disposable ?s= result URLs are simply left behind. ## On-site search is a feature, not content The distinction that makes this simple is that search is behavior, not a page. On WordPress, typing in the search box runs a live query against the database and assembles a results page on the fly. Nothing about that is stored content that a migration moves; it is a function the platform performs. So when the platform changes, the search function has to be rebuilt, the same way a contact form or any other interactive feature is reconstructed rather than copied. This is why search is a rebuild task, not a content task, and it is also why it is straightforward: you are recreating a well-understood feature, not preserving a fragile artifact. ## The ?s= result URLs are disposable A common worry is what happens to search result URLs, but this one resolves in your favor. WordPress produces result pages at addresses like /?s=keyword, and those are dynamic, low-value pages that should be kept out of the index anyway, which is why good setups apply [noindex to them](https://developers.google.com/search/docs/crawling-indexing/block-indexing). They are throwaway by nature: infinite in number, thin in content, and useful only in the moment. So unlike your real pages, there is nothing here worth preserving in a [site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). If a few ?s= URLs somehow got indexed, they drop out harmlessly after migration. You do not redirect them, you simply do not carry the concept forward, and that is correct. ## How search works on the rebuilt site On the new site, search is typically served one of two ways, and both are solid. A prebuilt search index is generated when the site is built, so the browser can query it instantly without any live database, which suits most content sites and is genuinely fast. Alternatively, a hosted search service maintains its own index and returns results, which suits larger or more complex needs. Either way the visitor sees a normal search box and gets matching pages, and because the index is prepared in advance rather than queried from a loaded database, search often feels quicker than it did on WordPress, part of why a [static rebuild tends to be faster](/is-static-website-better-than-wordpress-performance) overall and helps [Core Web Vitals](https://web.dev/articles/vitals). ## Search only needs your migrated content The reassuring dependency is that search indexes whatever content is on the new site, so if the migration brought your pages and posts across, search has everything it needs to work. There is no separate search database to migrate; the index is built from your content. This means search comes along almost for free once the content is in place, provided the rebuild includes the step of generating the index. It also means the quality of search follows the quality of the migration: a complete content move gives complete search, which is another reason to confirm [everything came across](/will-an-ai-website-builder-import-my-existing-content) rather than assume it did. Content first, then the index over it. ## Match the approach to your needs Choose the search approach to fit the site rather than defaulting blindly. For a typical blog or business site, a prebuilt client-side index is fast, simple, and free of external dependencies. For a large catalog or a site that needs faceted filtering, sorting, and typo tolerance at scale, a dedicated hosted search service earns its place. The point is to decide deliberately in the rebuild, sizing the solution to how much content you have and how people actually search it, since traffic and engagement concentrate on a minority of pages anyway, as the [Ahrefs study](https://ahrefs.com/blog/search-traffic-study/) shows. A right-sized search is better than an over-engineered one for most sites. ## Steps to handle site search in a migration 1. **Treat search as a feature to rebuild**, not content to copy. 2. **Ignore the ?s= result URLs:** they are disposable and need no redirect. 3. **Migrate your content first**, since the search index is built from it. 4. **Choose an approach:** a prebuilt index for most sites, a search service for large or faceted needs. 5. **Generate the index** as part of the build so search works at launch. 6. **Test real queries** after launch to confirm results are relevant and fast. ## Worked example: faster search after the move Consider a documentation site whose visitors leaned heavily on the search box to find articles. On WordPress, search ran against the database and felt sluggish as the site grew. Migrating to a rebuilt static site, the team did not try to preserve the old ?s= URLs, which had always been noindexed, and instead generated a prebuilt search index over the migrated articles at build time. The search box looked the same to visitors, but results now returned instantly from the in-browser index. Because all the articles had migrated, the index covered everything, and testing a handful of real queries confirmed relevance. Search ended up faster and simpler, with no disposable result URLs to worry about. ## Limitation: complex search may need a dedicated service It is honest to bound this. A prebuilt index handles most sites well, but genuinely complex search, huge catalogs, faceted filtering, multilingual relevance, or real-time inventory, can outgrow it and needs a dedicated search service, which is a deliberate cost and setup rather than a free byproduct of the migration. Very large indexes also add weight if handled naively, so they should be built and loaded with care. So scope the search solution honestly: simple for simple needs, and a proper service where the requirements are real, rather than assuming one approach fits every site. ## Key points When you migrate off WordPress, on-site search is rebuilt as a feature, because WordPress search is a live database query that a static or rebuilt site reimplements with a prebuilt index or a hosted search service, usually faster than before. The ?s= search result URLs are disposable pages that should never have been indexed, so there is nothing to redirect; you simply leave them behind. Search indexes your migrated content, so a complete content move gives complete search, provided the build generates the index. Match the approach to the site, a client-side index for most, a dedicated service for large or faceted needs, and test real queries after launch. WPBuildAI rebuilds on-site search with a fast index over your migrated content, so visitors can still search the site while the disposable result URLs are left behind. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.