Critical

1. Custom slugify doesn't match github-slugger — fumadocs uses github-slugger (via remark-heading.js) to generate heading id attributes in the rendered HTML. The PR introduces a custom slugify function that behaves differently. Key differences:

   • github-slugger preserves non-ASCII characters (e.g., accented letters, CJK); the custom regex /[^\w\s-]/g strips them.
   • github-slugger handles duplicate headings by appending -1, -2, etc. The custom function doesn't.
   • github-slugger converts spaces differently for certain edge cases.

   This means clicking a heading search result will navigate to #wrong-slug and the page won't scroll to the heading. Use github-slugger directly — it's already a transitive dependency via fumadocs-core:

   import Slugger from 'github-slugger';
   const slugger = new Slugger();
   // reset per document, then: slugger.slug(headingText)

2. Duplicate heading disambiguation is missing — If a page has two headings with the same text (e.g., two "Example" headings), github-slugger generates #example and #example-1. The custom slugify generates #example for both, so the second heading result would scroll to the wrong one. Using github-slugger with proper per-document reset fixes this.

Issues

3. Slugger state must be per-document, not per-heading — github-slugger tracks seen slugs to deduplicate. If you create one slugger instance and use it across all documents in the search results, the dedup counter will carry across pages. You need to instantiate a new Slugger() (or call slugger.reset()) for each document/page when building the index. The correct place to compute heading slugs is during buildDocs (indexing time), not in findMatch (query time), since you need the full list of headings per page to get dedup right.

4. deduplicateByUrl in search.tsx strips anchors — The client-side deduplicateByUrl function (line 188-196) does r.url.split('#')[0] and deduplicates by the base URL. This means if the same page has two heading matches, only the first one survives. Before this PR that was fine (all results for one page had the same URL), but now heading results have distinct #anchor URLs and should probably not be deduplicated against each other. Consider deduplicating by the full URL (with anchor) when match type is heading, or removing the dedup for heading results.

Minor

5. Headings in the search index may contain markdown formatting — The heading extraction regex line.match(/^#{1,6}\s+(.+)/) captures raw markdown text. A heading like ## Using \config.yaml`stores the backticks in the headings column. The custom slugify strips them, butgithub-sluggerwould produce a different slug than the rendered HTML where backticks become` and are stripped during flattening. Consider stripping inline markdown formatting before slugifying.

6. Body match could also benefit from anchor links — If the query matches body text near a heading, you could include the nearest preceding heading's anchor. Not required for this PR but would be a good follow-up.