@dorothyyeager @JonellaCulmer. Three options below:

1) Can we just link the title like this?:

2) Or do you want to add the extension and size and link the extension, like this?:

3) Or both, or something else?

@johnnyporkchops I'll defer to @JonellaCulmer but I am good with either of those options. It seems like just the link is less work and gets the job done, so that's my vote.

@johnnyporkchops @dorothyyeager @AmyKort I can mock something up if we want these pages to have the document links on them instead of linking directly to the document from the global search, which is my preference. We already have an icon in the global search that suggests what customers are clicking on is a document.

@JonellaCulmer , the only way to force a search-result webpage-link to go to a link to a document (or any other address) is to redirect it.

For the pages with the document link, we can also link from the Category button above to a filtered parent:
Example: /about/reports-about-fec/oig-reports/?category=inspection+or+special+review+report&year=2023

@johnnyporkchops What's the level of effort on the redirects? I think it would be cleaner for customers to click on the link in the search and go directly to the PDF. As you said, these pages were not intended to be seen.

@JonellaCulmer, We might want to ask @dorothyyeager because redirects are her expertise, but it would mean creating about 420 redirects and then having to create a new redirect every time a new document is created. There is no way to do a global redirect pattern for these pages because the file name is different than the document/page title.

While it does represent an extra click to get to the document from a search result, the interim step is not totally useless because it orients the user to where they are in the ecosystem of Reports about the FEC and shows the same info you would get when using the search filters there (date, file size, category, file-type). It also gives the user a path to search other related documents if thats not the one they wanted.

Although the pages were not originally meant to be seen, the DocumentPage template was created with some foresight (building some fields into the template) We just need to add the others.

@johnnyporkchops Here's the mockup for the intermediary step while we work on the longer term fix.

@dorothyyeager @AmyKort
The current plan for the longer term fix would be to explore the removal of document pages from the global search results or redirect them and @johnnyporkchops will spend some time during innovation exploring the options. The end goal would be to bypass these document pages and go directly to PDFs. So even if we implement this intermediary step, we'll later remove the extra click and customers won't lose any time.

• We can create a sitemap for all these documents so the documents are indexed instead of the webpages. [DRAFT] Sitemaps for reports and FECForms - working prototypes #5958
• We would have to make all the docment pages prvate so they do not show up in Wagtail sitemap
• May need to ask search.gov to manually remove the pages already in the index. Or since they all have a path reports-about-fec/<section>/<page> , we may be able to ask search.gov to put a setting on their dashboard to exclude these paths. But we do not want to exclude the section parent, just the child pages.

Closing for now, work has been merged to fix links to documents. Longer term issues to link directly to documents from search and bypass these pages entirely.