List content not rendering url in search results

First I will mention this is similar to the issue presented here: http://www.sitefinity.com/developer-network/forums/developing-with-sitefinity-/sitefinity-search-on-dynamic-module-resulting-no-url

 I have two lists and each are assigned to a different page.  When doing a search on some terms found in the list items I will get search results showing the title and summary content, but the title is not rendering a valid url like it should be.  

From what I can tell this stems from not having a default publish page set for this content for the search index to know about.  I have tried following the solution found in the above thread I linked, but that only works if you have 1 page in question where all lists are going to display.

Then I came across this documentation: http://www.sitefinity.com/documentation/documentationarticles/default-pages-for-content-items

 Going to "Content -> Lists -> List" and then clicking on Pages where lists items are published results in No pages has been set to display content like this (side note:  If using the plural you should use "have" instead of has)

So basically I do not see how I am supposed to setup a priority list of default pages to make this work.

Hi Stacey,

Thank you for using our services.

In order to have any pages under the settings "Pages where List Item items are published", you need to have at least one List widget set to "Page list (open each item in separate page)" (screenshot).

Please let me know if the proposed solution helps.

Regards,
Svetoslav Manchev
Telerik

Hello Svetoslav,

Thanks for getting back to me.  I understand your answer, but I do not think it makes sense that the list widget would offer all those options for rendering lists, but only one of them is pseudo-compatible with search indexing.  Unfortunately this does not help me as I am rendering the list items as an expandable list.  For now I have had to remove lists from the search index to prevent users from being confused.

A suggestion I have is that if Sitefinity needs to have default pages set for certain content then perhaps allowing separate default pages per list rather than all lists would make more sense.

Its a huge flaw in the canonical logic to assume all items of a type only exist in one spot... even the concept of a  'default' drives us nuts.

Its possible for Sitefinity content to exist in the backend and NOT exist on the frontend though filters and such... this is where the current implementation just falls apart.  Like if you set a widget to be in Automatic mode then you can throw ANY UrlName into the url and it'll render regardless of if the masterview filter says it should render.  The whole concept of a default place for all items of a type should be scrapped and replaced with a GRANULAR system that globally specified where specific items appear.

Hello Stacey,

The other List display options are actually rendered as static Html, so in order to have url for these Items, you can set indexing "Static HTML in pages", remove the "List Items" and reindex.

Than in the search result you should have the url of the page where this List Item content is placed.

Regards,
Svetoslav Manchev
Telerik

Hi Stacey,

I just came across this same issue on a client's website and using this thread as a basis i came up with the following solution:

- Create a new page, using the existing page as a parent

- Set this new page to have a title indicating that it's a single item (e.g. if dealing with FAQs, call the new page FAQ)

- Set the page to not show in navigation, don't allow site search to index this page, don't allow external search engines to index this page

- Add the list to the new page, setting the list type to "Page list (open each item in separate page)"

- Edit the single item template, including a link back to the existing page which displays all list items (or alternatively utilise a breadcrumb control)

This method will allow your list items to appear in search results with a link directly to the information the searcher was looking for and the ability to link back to see the information in context.