Why XWiki search configuration decides whether a knowledge base gets used
When people in a self-hosted XWiki cannot find pages, they stop searching and start asking colleagues or creating duplicate pages, and the knowledge base loses its purpose. Search quality depends on three things: the search index, the permissions applied to results, and the way content is structured into spaces, pages and metadata. Each needs a deliberate setup decision before users arrive. After a migration or upgrade, the index may hold stale or partial content, so the problem often appears only once real volumes of pages are in place.
This is harder than it looks because the index is a separate artifact from the pages. Content can be saved correctly while the index lags behind, and a rebuild on a large wiki takes time and server resources that must be planned around normal use. Results also have to respect rights. A search that returns pages the user cannot open is a security issue, while a search that hides too much makes the wiki look empty to the people who should benefit from it most. Rights-aware results therefore need testing with real user accounts, not only administrator views.
Some search features also depend on extensions rather than on the core product. Whether a given search capability, filter or result presentation is available, and how it is configured, depends on which extensions are installed and on the XWiki line you choose. The search backend and its settings differ across the stable, long term support and intermediate LTS lines, so the exact configuration keys, index behavior and extension compatibility must be confirmed against the release documentation for your version before you commit to a design.
Large page counts raise the stakes. Relevance tuning that works on a pilot space can behave differently once thousands of pages share the same vocabulary, and duplicated or outdated pages compete with the authoritative ones. Ask the team who owns each space, which pages are meant to be found, and how stale content is retired. Plan an index health check for each migration, upgrade and major content import, and record the index state, the rights test results and the search scenarios you verified, so the result can be repeated and audited later.
Which search decisions to settle before configuring the index
This table compares four decisions that shape XWiki search: release line, index scope, rebuild strategy and tuning approach. Read each row for when an option fits and what it costs to run, then settle the choices in writing before anyone edits index settings. The main takeaway is that scope and release line are expensive to change later, so decide them first.
| Decision | Option and when it fits | Operational cost | What to confirm first |
|---|---|---|---|
| Release line | Stable line when you accept more frequent upgrades and want new search fixes sooner. LTS line when you want a longer upgrade window and fewer search-related changes between planned moves. | Search extension versions follow the chosen XWiki line, so each upgrade may change index behavior and needs a search regression pass in staging. | Which XWiki line your upgrade policy supports, and whether your search extension versions match that line. |
| Index scope: spaces | Index only spaces that hold knowledge users search for. Exclude sandboxes, archives and migration staging spaces to keep the index focused. | Narrower scope lowers index size and rebuild time. Adding spaces later usually means reindexing them, which takes time on a large wiki. | Which spaces are in scope for search, and who owns the decision for each space. |
| Index scope: attachments and extensions | Index attachments when users search document content such as PDFs or office files. Index extension-provided content only when it is useful to searchers. | Attachment indexing grows storage and extraction workload. Each added content type adds testing of extraction results. | Attachment types and volume, and whether text extraction is needed for them. |
| Rebuild strategy: full rebuild | Use a full rebuild after a major migration, a schema change, or when the index is suspected to be corrupted or out of step with content. | Requires planned time for reindexing during which search results may be incomplete. Run it in a maintenance window and measure duration in a test instance first. | Acceptable search downtime or degraded search, and whether users can be told in advance. |
| Rebuild strategy: incremental updates | Use incremental updates for steady-state operation after the initial build, when content changes are regular and the index is healthy. | Lower routine disruption, but errors can accumulate silently. Schedule periodic checks that compare index contents with wiki content. | Whether your monitoring can detect stale or missing index entries. |
| Tuning: built-in options | Use built-in configuration first for ranking, scope and indexing behavior, since it keeps upgrades simpler and needs less custom testing. | Low build cost, but options may not cover every ranking need on large or specialized wikis. Document each change for upgrade reviews. | Which built-in settings meet the search requirements in your pilot. |
| Tuning: custom extensions | Use custom code only when built-in options cannot meet a documented requirement, such as special ranking or indexing of a specific content type. | Adds ongoing maintenance, compatibility checks at every upgrade and a dependency on whoever maintains the code. Factor this into the support plan. | Who will maintain the code after go-live, and how upgrade testing will cover it. |
How to configure XWiki search in a staged sequence
This sequence moves XWiki search from a documented baseline to a verified production setting without guessing at behavior. Each stage produces a record that the next stage checks against, so index problems surface on a copy of production before users see them.
Confirm the XWiki line and image tag
Record the XWiki line your deployment runs before changing any search setting. At research time the official Docker tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, but confirm the current tag against the official image library file because tags change. Record the database variant (MySQL, PostgreSQL or MariaDB) and the host architecture too, since the test copy must match production on each point. This step is done when one written record names the exact tag, variant and architecture for both the test copy and production, and the two match.
Verify search components for that version
Read the release notes and documentation for the chosen line to identify the search components, index engine and default search-related extensions it ships with. Do not assume these match the version you ran before, because components can differ between lines. Check the installed extension versions in the administration interface and note any extension that replaces or adds to a default search behavior. This step is done when you hold a list of components with their versions, each one traced to a source, and any unexpected extension has an owner and a decision.
Set the index scope
Decide which wikis, spaces, document types and attachments are indexed, and which are excluded. Typical exclusions to evaluate include archived spaces, personal spaces and sandboxes, but each exclusion should follow a written policy owned by the business. Use the page inventory to record the expected page count for each included space and the count you expect to be excluded. This step is done when a scope document lists included and excluded spaces with expected counts, and an approver has signed off on it.
Run a full index build on a production copy
Restore a recent production backup into an isolated environment that matches the confirmed tag and configuration. Run a full index rebuild there rather than relying on incremental indexing, and record the start time, end time and any aborted or failed jobs. Compare the number of indexed documents with the expected counts from the scope document, accounting for the excluded spaces. This step is done when the build completes without aborted jobs and the indexed counts reconcile to the page inventory, with any gap explained in writing.
Check indexing logs for errors
Review the servlet container and XWiki logs from the full build for indexing exceptions, skipped pages, malformed content and macro failures. Group the findings by cause, such as broken macros, invalid content or permission lookup errors, and assign each group an owner. Fix the causes that affect search results, then run the build again and compare the new log output with the first run. This step is done when every error group is either fixed or accepted in writing, and the repeat build produces no new error types.
Test queries per space and rights group
Build a test matrix with, for each space, several queries whose expected pages you already know from the inventory. Run each query as an account from every rights group, and include a guest account if guest access exists. Confirm that expected pages appear and that pages a group cannot view never appear in its results. This step is done when every test query returns its expected pages and no restricted page appears for an account without view rights. Record any failure with the query, account and expected result.
Enable on production with a rollback plan
Before the change window, back up the production database and save the current search configuration and index state. Write the rollback trigger and steps in advance, including who can authorize a revert. Enable the approved configuration, rebuild the index as tested, then run the same test matrix against production using dedicated test accounts. This step is done when the production test matrix passes and the rollback has been rehearsed on the copy. If the matrix fails, revert to the saved configuration and restore the prior index.
Keeping the search index healthy after migrations and upgrades
The search index is a separate copy of your wiki content, so it can fall out of step with the database after a Confluence import, a bulk page load, a database restore or a version upgrade. Each of these events writes or replaces pages, and the index only stays accurate if every change passes through the indexing path. When it does not, users see two symptoms. A migrated page opens fine but never appears in search, or search returns a page that was moved, deleted or restricted. Users usually spot the first symptom when they search for a recent title, and the second when a page surfaces for someone who should not see it. Treat indexing as part of each event's acceptance criteria, and name one owner to run the checks before users are invited back.
Start each post-event check by deciding the reindex scope. If the event touched only a few spaces, reindex those spaces so the work and the impact stay small. If it replaced content across the wiki, such as a database restore, plan a full rebuild instead. Next, compare counts between the database and the index for each space. Export page counts from the database and document counts from the index, then investigate every difference that the migration or load report does not explain, such as pages intentionally excluded. The exact count queries and index inspection methods depend on your XWiki version and index configuration, so confirm them with your implementer and record them in the runbook before the event starts.
Spot-check restricted pages next. Choose pages in spaces with narrow rights, including pages where a deny rule or an inherited right decides access. Search for their titles and a distinctive phrase while logged in as test accounts from each group that should see the page and from each group that should not. Script this check with named accounts and keep the results. A search result that exposes a restricted page to an unauthorized user is a security incident that needs its own review, so it should block sign-off. Add attachments to the same pass. Confirm whether attachment content is indexed in your installation, search for a phrase known to appear inside a sample PDF or office file, and check that the result links to the correct attachment.
A full rebuild is the right response when counts diverge across many spaces, when a database restore brought back content without its matching index, when restricted-page checks fail anywhere in the wiki, or when a release changes how the index is stored. For the last case, check the release notes for your line, and keep the upgrade steps themselves in the upgrades topic. Ask the implementer for the expected search impact during a rebuild, the time window, whether users can keep editing, and how long results may be incomplete. Also ask for the rebuild command, the log locations, the success criteria and a rollback path. Migration workflow details are covered in the migration topic.
What drives search effort and cost in large XWiki wikis
This table lists the factors that change how much work search configuration takes on a large XWiki wiki, and how each one can be kept under control. Read each row as a question to answer during scoping: how big is this factor in your wiki, and which control keeps it manageable. The main takeaway is that volume alone rarely decides effort; rights design, extensions and the number of environments usually multiply it.
| Driver | How it raises effort | What keeps it down |
|---|---|---|
| Page and attachment volume | A larger index takes longer to rebuild after migrations or upgrades and needs more verification of result quality. Attachment content extraction adds indexing load that pages do not. | Scope pilot spaces first, index a representative sample before full import, and confirm attachment indexing scope with your extension list. |
| Spaces and nesting depth | Deep space trees complicate scoped searches, facets and result relevance, and each level can need its own test queries. | Adopt a standard space template with a shallow, predictable hierarchy and document which spaces users search most. |
| Extension count and search impact | Each extension can add macros, document types or indexed fields. Extensions that change indexing must be checked after every upgrade, and conflicts can silently drop fields. | Keep an inventory of extensions that touch search, test them on staging before upgrading, and remove unused extensions. |
| Distinct rights groups | Search only returns pages a user can view, so many groups with different access produce many visibility combinations to test and explain to users. | Design rights around a small set of groups mapped from the directory, and test search results for a representative user from each group. |
| Language and content variety | Multiple languages need language-aware analysis and translated page versions. Mixed content types such as diagrams, code and structured data can need specific indexing and query tests. | Limit supported languages to those in active use, agree one primary language per space, and test queries in each language before go-live. |
| External content sources | Connectors or external data pulled into the wiki add sync schedules, duplicate content and freshness questions that search results must reflect. | Index only the sources users need, agree refresh expectations in writing, and confirm how each connector appears in search results. |
| Number of environments | Development, staging and production each need matching index configuration, and drift between them makes staging tests less reliable. | Keep search configuration in version control, apply it to every environment through the same process, and compare index settings before each release. |
Improving result quality for large wikis without over-tuning
The most reliable way to improve XWiki search results on a large wiki is to fix the content being indexed before touching ranking settings. Search quality usually suffers because pages are titled inconsistently, spaces have no meaningful homepage, pages are duplicated across spaces, and stale material from old migrations or abandoned projects competes with current documentation. Each of these problems is visible to users as the wrong page appearing first, and none of them is solved by adjusting weights. Before you change anything, ask your content owners which spaces are authoritative and which pages should no longer exist. Start with page titles, labels and space homepages. Agree on a naming convention for titles that includes the product or team name and the document type, and apply it to new pages first. Make each space homepage a real entry point that summarizes what the space contains and links to its key pages, because users often land there and search results tend to surface these pages for broad terms. Labels or tags should come from a short controlled list maintained by a named owner. Free-form labels multiply quickly and dilute the signal you rely on for filtering and ranking. Review macros that hide content from indexing before you rely on them. Some macros and scripted includes render content at display time, so the text may not be stored in a form the index reads the way users see it. Inventory which macros your most-viewed pages use, confirm with your XWiki administrator and the documentation for your installed version how each one affects indexing, and replace hidden content with plain text where search matters. Add metadata such as owner, status and review date through object or tag conventions only where a team will maintain them. Remove stale and duplicate pages before reindexing, because reindexing only refreshes what exists. Archive or delete pages past their useful life, merge duplicates into one authoritative page with redirects where needed, and record what you removed so owners can object. Then rebuild or refresh the index and measure. Changing ranking settings without measuring can hide these problems: a boosted page may move to the top for one query while the underlying duplicates and stale copies remain, and the next content change breaks the result again. Measure with a fixed set of test queries collected from real users, such as the search terms in your search logs or questions raised with the help desk. Record the expected best page for each query, run the set before and after each content or configuration change, and compare the position of the expected page. Keep the set stable so results are comparable, and expand it only on a documented schedule. Confirm with your XWiki version's documentation which search statistics and logs are available to you, because the measurement approach depends on what your installation records.
How search setup differs by deployment model
On a single node, the search index usually sits on the same host as the XWiki permanent directory, so there is one copy to locate, size and back up. Rebuilds run inside one application instance and need no cross-node coordination, but they compete with user traffic for the same CPU and disk.
- Index location: Confirm where your XWiki version writes the index relative to the permanent directory, and keep both on a volume your backup process already covers.
- Rebuild coordination: None across nodes. Schedule full rebuilds in a maintenance window because they share the host's resources.
- Index storage: Size the disk from index growth measured during a test import on a copy of your content, not from an estimate.
- Backups: Decide whether you restore the index from backup or rebuild it from the database after a restore, and test both paths.
- Extension testing: Install the search component and any search-related extension on a staging copy of the same XWiki version before production.
Before go-live, restore a recent backup to a separate host and confirm that search returns expected results without a manual rebuild, or record how long the rebuild takes.
With more than one XWiki node, search has to behave consistently across all of them. Each node must either share one index or keep its own copy with a documented way to keep copies aligned. Updates made on one node must reach the index that other nodes read, and a rebuild must never run on two nodes at once. The high availability topic covers database replication, load balancing and session handling, so this tab focuses on the search-specific decisions.
- Index location: Decide between a shared index location and per-node indexes. Confirm with the XWiki documentation for your version which layouts it supports.
- Rebuild coordination: Allow only one rebuild at a time, and make sure a rebuild started on one node does not get triggered on another.
- Index storage: Shared storage needs locking behavior confirmed with your storage vendor. Local disks need a documented synchronization path and a check that copies match.
- Backups: Back up the index at the same point as the database snapshot, or plan a rebuild after any restore so the two stay consistent.
- Extension testing: Install the component on one node in staging, then confirm every node runs the same version before traffic returns.
Before production, ask who owns the cluster-level search design, and confirm the layout in the high availability topic before any build starts.
XWiki publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. The XWiki Core Dev Team maintains them. A container's filesystem is replaced on every image update, so search data written inside the container is lost unless you mount it. Treat the index path as persistent storage that exists outside the image.
- Index location: Mount the index location and the permanent directory as persistent volumes, separate from the image.
- Rebuild coordination: If you run more than one replica, apply the same coordination rules as a clustered deployment and confirm the replica count against your search design.
- Index storage: Choose a volume class with I/O performance your platform team can measure during a rebuild.
- Backups: Snapshot the volumes together with the database. Image tags are not backups of your content or index.
- Extension testing: Pin the image tag to the XWiki line you tested. The official repository publishes stable, LTS and intermediate LTS tags, so verify the exact tag before pulling it.
After any image change, stop and recreate the container in staging and confirm that search still returns results from the same persistent volumes.
In an air-gapped environment, nothing reaches the public internet during install, rebuild or update. Search still depends on XWiki artifacts, extensions and their dependencies, so every item has to be collected, verified and staged inside your network before the change window. Rebuilding the index needs no outside service, but any missing dependency will block the install.
- Index location: Keep the index on the isolated network's storage, under the same rules you apply on-premises.
- Rebuild coordination: No external service is involved, so rebuilds depend only on local resources and the coordination rules for your node count.
- Index storage and backups: Store backups on media your security policy allows, and test a restore inside the isolated network.
- Extension testing: Build an inventory of the search component and every dependency, stage them in an internal artifact repository, and install them in a test environment with no outbound route. Confirm the component loads and search returns results.
- Image and update flow: Transfer container images or packages through your approved process and verify checksums on the internal side.
Before the production change, run a complete install from the transfer bundle in a disconnected lab and record any dependency that was missing.
Access control, index storage and secrets in search
Search can expose content that page rights were meant to hide, so access checks must cover more than the pages themselves. Each card below names one place where access control can slip and one check to run before go-live and again after upgrades or reindexing.
Results must respect page rights
Search results should show only pages a user is allowed to view, but confirm this on your own wiki before go-live rather than assuming it. Sign in as several test accounts that cover each group, restricted space and guest access level, then run the same queries and compare the results with what each account can open. Include pages with denied view rights and pages that inherit restrictions from parent spaces. The rights and permissions topic explains the underlying model.
Restricted content in attachments and extensions
Text inside attachments and content added by extensions can end up in the index, and page rights do not automatically cover every copy. List which file types your wiki indexes, which extensions add searchable content, and whether guest or broad group access can reach restricted material through search snippets. Test with a sample restricted attachment from each category. Decide whether to exclude sensitive spaces or file types, and record that decision for your security review. The security hardening topic covers guest access and extension auditing.
Index storage and backups hold content
The search index keeps copies of page text and metadata, so it is sensitive data in its own right. Identify where the index is stored, who can read that location, and how it is included in backups and snapshots. Restore a backup to a separate host and confirm that search returns the same restricted results as the source system. Apply the same encryption, access control and retention rules you use for the database, and keep a record of where every copy lives.
External search and connector credentials
Any external search service, connector or indexing account used by XWiki holds credentials that can read wiki content. Keep these in a secrets manager or protected configuration only, out of page content and plain text files. Give each credential the narrowest read scope the connector supports, and confirm the exact scopes with the connector vendor. Assign a named owner to a rotation schedule, test rotation in staging, confirm that old credentials are revoked, and review access logs for use from unexpected hosts.
How to verify search returns the right pages to the right people
A search test passes only when each person sees the right pages and nothing else, so the verification plan starts with a fixed query set and a written expectation for every query. Build a test matrix with one row per query, the account or rights group that runs it, the pages that must appear, and the pages that must not. Choose queries that cover each kind of space in the wiki, including exact titles, body phrases, attachment names and common terms that match many pages. Run every row as a test account from each rights group, including guest access if your design allows it. Confirm the group list and expected results against your rights design before the first run, because a matrix built on wrong assumptions will pass for the wrong reasons.
The negative checks matter more than the positive ones. For each restricted page, search for its exact title, a distinctive phrase from its body, an attachment name and any tag or author value a user could guess. Each query should return nothing from that page for an unauthorized account. Include pages that inherit restrictions from a parent space and pages where a deny rule overrides an allow rule, since these are the cases most often missed. Repeat the checks after a group membership changes or a page moves, because a stale result after either change is a leak even when the rights themselves look correct. Confirm with XWiki documentation for your version how rights are applied to search results, and whether any installed extension changes that behavior.
A restore that brings back pages without a matching, healthy index is a common cause of wrong results. After any simulated restore, rebuild the test environment from the backup set and rerun the full matrix before anyone treats the instance as usable. Compare the results with the baseline from the original run. Look for pages that reappear with old permissions, pages missing from results entirely and attachments that still match after they were removed. Run the same matrix after upgrades and after migration cutover, since both change content and the index. Record who ran each test, which build and index state was used, and when each run happened, so the evidence can be reviewed later by your own team or an independent assessor.
Decide in advance what happens when a check fails. The safe response is that search does not serve results it cannot filter correctly. A degraded index should show an error or an unavailable message, and never partial or unfiltered results, and the team should see that state in monitoring. The failure path has three steps. First, trigger a full reindex from the source content and rerun the complete matrix. Second, if the matrix still fails, roll back to the documented previous state, including the database snapshot, the index backup and the extension versions. Third, record the defect, the rollback decision and its owner. Confirm with the vendor and your administrators how a full reindex is started, how long it takes on your data volume, and whether search can be disabled cleanly while it runs. Rehearse the rollback before go-live.
What to monitor, rebuild and document after go-live
This table lists the checks that keep XWiki search healthy after go-live, with the owner for each, the cadence to confirm with your team, and the artifact that passes to operations. Read it as a handover checklist, where each row needs a named owner and a stored artifact before cutover. The main takeaway is that index health depends on routine checks and a tested reindex runbook, not on the initial installation alone.
| Item | Owner | Frequency to confirm | Handover artifact |
|---|---|---|---|
| Indexing errors and logs | Platform operations engineer | Confirm with the team, with a review after every upgrade, import and extension change | Log locations, alert rules and a triage guide for indexing exceptions in the XWiki and Tomcat logs |
| Index-to-database count checks | XWiki administrator with a platform engineer | Confirm with the team, aligned with the content change rate in large spaces | Saved check script or procedure comparing indexed document counts with database page counts, plus expected tolerances |
| Scheduled reindex or rebuild triggers | XWiki administrator | Event-driven: after each upgrade, Confluence import, bulk load or search extension change | Trigger list mapping each event to a reindex or rebuild step, with the person who approves it |
| Backup of index data alongside the database | Database and backup administrator | Confirm with the team, with the backup schedule set to match the database backup | Backup policy covering the database and index data, with the restore order and a dated test restore record |
| Extension version records | XWiki administrator and change owner | Confirm with the team, updated on every extension install, update or removal | Inventory of installed extensions and versions, linked to the XWiki version and the upgrade test results |
| Reindexing runbook | Platform engineering lead | Reviewed after each upgrade and after any search incident | Step-by-step runbook covering preconditions, the reindex steps, verification queries, rollback and escalation contacts |
Questions teams ask before configuring XWiki search
What drives the cost of XWiki search configuration work?
The cost depends mainly on how much of search behavior is standard and how much needs tuning. Main drivers: the number of spaces, pages and attachments, the languages in use, whether search must cover applications, custom macros or structured data, how many search scenarios need testing, and how many environments are covered.
Who pays for what: with DeployOpen, you pay for the scoped work defined in a written agreement. Internal staff time is an internal cost that does not appear on an invoice but still needs to be counted.
One-time versus recurring: analysis, configuration, testing and documentation are usually one-time. Re-tuning after upgrades, or a retainer for ongoing support, recurs.
Ask for in a quote: a list of deliverables, the environments included, the test cases, and how scope changes are priced. The implementation plan topic explains how to scope the work.
How long does XWiki search configuration usually take?
No general duration is given here, because the answer depends on the factors that shape the work. A wiki with default search and a small set of tuned results takes far less effort than a large wiki with many languages, attachments and custom applications.
Drivers that lengthen the work: the number of search scenarios to verify, the number of reviewers who must sign off on results, the number of staging cycles needed, and whether the work runs alongside a migration or upgrade.
Dependencies to confirm: when a staging copy will be available, when content owners and test users can respond, and when access to logs is granted.
Ask for: a timeline tied to a written scope, with each dependency and sign-off date listed. The migration and upgrades topics show where search work fits in a larger schedule.
Can our internal team configure XWiki search without outside help?
Yes, a team with Linux, servlet container and XWiki administration experience can configure search internally, provided it has time, a staging environment and someone who understands the content.
Where internal teams usually do well: routine checks, documenting settings and running test queries.
Where it gets harder: reading index behavior from logs, deciding how results should rank for your content, and writing a repeatable procedure for later upgrades.
Check before deciding: whether the team holds the administrator rights it needs in XWiki, has access to the servlet container and database, and can schedule tests with business users.
Where outside help fits: a fixed-scope review, an independent check before go-live, or a runbook your team can follow later. The implementation plan topic lists the skills to confirm.
What do we need to provide for an XWiki search project?
The project needs four kinds of input from your side.
Content owners name the spaces that matter most and confirm what a good result looks like for common queries.
Test users from different roles run realistic searches and report misses, so the testing reflects how people actually look for information.
A staging copy of the wiki, including a recent database dump and attachments, lets changes be tried before production.
Access to logs, including application and servlet container logs, shows indexing errors and query behavior.
You should also provide the exact XWiki version, the extension list, and a named contact who can approve changes. Confirm the access model in writing before work starts, especially for production logs and database access.
How do we know whether the XWiki search index is healthy?
A healthy index returns new and edited content within the time your users expect, drops deleted content, and returns the pages a person would expect for a set of known test queries.
Checks to run:
- Look for indexing errors in logs after saves and imports.
- Compare the pages found in the wiki with the pages search returns for a sample of spaces.
- Confirm that page titles and attachments are searchable, if your users need them.
- Watch for missing or duplicated results after migrations.
Run the same baseline queries after every change and keep the results. Define these checks as acceptance criteria before work starts. Confirm with the documentation for your XWiki version which index operations and administration tools are available.
Will an XWiki upgrade break our search configuration?
It can, so treat every upgrade as a search test. Changes in the XWiki core, in extensions, or in how the index is stored may alter results, ranking or the way existing configuration is read.
Common risk points: extensions that add their own search fields or macros, and custom settings that were made by hand in the interface.
Before upgrading: run a staging upgrade on a recent copy of your data, repeat your baseline queries, and compare results. Read the release notes for the target line and confirm extension compatibility first.
Reduce future effort: keep configuration in version-controlled files where possible, so it can be reapplied. The upgrades and support topic covers choosing a release line and testing extensions before a move.
Do we need to check search after a bulk content import?
Yes. A bulk import, such as a move from another wiki, changes many pages at once, so search results should be verified before users rely on them.
What to check: that imported pages appear in search, that page titles and key terms return the expected pages, and that attachments are searchable if your users depend on them. Look for duplicates and for pages that exist in the database but are missing from results.
How to verify: compare samples from each imported space against the source, and run the baseline queries agreed with content owners. Confirm with your XWiki version's documentation how to trigger a reindex and whether it needs downtime.
The Confluence migration topic covers what transfers and what needs manual rework, which affects what search should find.
How DeployOpen scopes, builds and hands over XWiki search work
DeployOpen treats XWiki search configuration as a defined piece of work inside a self-hosted XWiki deployment in infrastructure you control. We agree the scope in writing first, then build and test the index and search settings, then hand over documented procedures your team can run.
How we scope
- Review which XWiki line you run, stable, LTS or intermediate LTS, and the search settings it currently uses.
- Inventory the wikis, spaces and content volumes that search has to cover, including any Confluence imports.
- Agree in writing which index checks, configuration changes and test searches are included in the fixed scope.
How we build
- Configure the search index and its rebuild procedure on the environment you provide, with changes tracked in version control.
- Test search results against representative queries, checking that pages your users need are found and that restricted pages stay hidden.
- Verify index health after a migration or upgrade, and record the steps needed to rebuild the index safely.
How we hand over
- Deliver a written runbook covering index rebuilds, scheduled checks, and the settings that affect result ranking.
- Walk your platform and administration team through the procedures and the test queries used during acceptance.
- Document any search-related extensions, their versions and the upgrade checks to repeat before each XWiki update.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover index health after future upgrades.
- Retainer scope is agreed in writing, so you know which search checks recur and which need a new engagement.
- Ask for a quote based on your written scope, since DeployOpen does not publish a price list.
