This isn't an issue of Smart Search, but of the routing. There simply is no menu route to the mentioned categories and thus it falls back on the home menuitem. That then again results in a 404 URL. Don't know how to fix this yet, but marking it as a com_finder/Smart Search issue is missing the point.

You missed the point ...

These are the ONLY categories in my site:

Uncategorised = ID 2
Blog = ID 8
Help = ID 9

Yet in the search results there are links to categories with id 7 and 3

All I have done is install Joomla 4 and Sample Blog Data and then Index the site. THE CATEGORIES with id 7 and 3 DO NOT EXIST and therefore these categories should never be in the Index...

@PhilETaylor
if you display administrator/index.php?option=com_finder&view=index and filter by category, do you find your ids?
Likely Uncategorised for users, banners, or newsfeeds I guess.

I was reading the MySQL table directly

I'll try again today

@gostn You have obviously not followed the steps to replicate the bug FROM A CLEAN SLATE as the "Blog Sample Data" doesn't install other languages.

@infograf768 I have checked the database direct again today - and there many more categories than the three I saw the other night :-(

After INDEXING the "Blog Sample Data" right after installing it you get this:

Then on the frontend (using the bug in #30967) you see:

So the BUG here is that the links are missing the option=com_XXX param in the URLS.

For example, using the screenshots above you can see the 7 is com_users, and option=com_users is missing in the URL of the first search result http://127.0.0.1:4444/index.php?view=category&id=7

However even if I add that suffix I then get a 404 at http://127.0.0.1:4444/index.php?view=category&id=7&option=com_users

You have obviously not followed the steps to replicate the bug FROM A CLEAN SLATE as the "Blog Sample Data" doesn't install other languages.

thats why i filter languages to ´all´.

The only way to test something is from a clean slate and then following the "steps to reproduce" provided.

Working on a site with changes already can cause all kinds of side-issues. Maybe not in this case on this issue, but it will trip you up more times than you will want to admit. Always start from a clean known state :)

Working on a site with changes already

the "changes":

There is a bug indeed

So the BUG here is that the links are missing the option=com_XXX param in the URLS.

Correct. And I also wonder why you get these results when searching for PhilTaylor

@gostn Yes but the steps published to reproduce say to use the "Blog Sample Data" and not the "Multilingual Sample Data" - for this issue it made no difference, but in future it might

@infograf768 Maybe its all related to the parent issue this forked from - maybe I should never see these results if the bug #30967 was fixed?

Yes but the steps published to reproduce say to use the "Blog Sample Data" and not the "Multilingual Sample Data

i used both as always so what.

You can do what ever you want... all I am saying is that the correct way to test is from a known clean state, and that is to follow the "Steps to reproduce"... this time you got away with it, that might not always be the case :) Up to you though.

@PhilETaylor I did understand you correctly and I followed your instructions. As you noticed yourself, there are more categories in your site than those 2 that you saw. I assumed that it is a problem of the router and not the search. When enabling SEF URLs, the router tries to somehow connect the URL to a menu item. If that fails, it falls back on the home menu item. URL query parameters, which are already given by the menu item, are removed. In your case that is the &option=com_content, which leaves the &view=category&id=7.

However on deeper inspection, it is an issue of the categories indexing plugin. The plugin was indexing categories for components without a frontend view for them, thus without anything to display. Someone thought it might be a good idea to simply fall back on the com_content RouteHelper. So the given URL was index.php?option=com_content&view=category&id=7, while it actually should have been for com_users, which doesn't have a frontend category view and thus this category shouldn't even be indexed at all.

The fix for this is in #31041