tl;dr A summary section is added at the end
You’re not saying which tools you’re using or are ready to use, so I’m assuming either the builtin search or the Dataview plugin. In general it can be said though that even though we as humans think of a paragraph as a separate entity/logical unit, Obsidian and/or Dataview are not necessarily operating at that level.
They usually either work with the page/note as a whole unit of work, or through a little manipulation section/lines, or list and task items.
Simple test document
Here is a very rudimentary test document to help me illustrate the various points in this answer.
https://somewhere.com/ Tourist destination? #bookmarks #2024-06-01
https://dell.com My new fabulous computer #bookmarks #2024-07-02
Design app... I have an idea #message #2024-06-03
Using the builtin search
If you wanted to locate the bookmark on the tourist destination and you knew you made a note on it in june, a naive search for this would be tag: bookmarks tag: 2024-06, which would fail with no matches since the tag is longer than just 2024-06. Now you could either loose the tag: selector, or specify the tag fully.
With no tag, i.e. tag: bookmarks 2024-06, you’ll get 4 results, and it’ll display all three paragraphs. With a specified tag, i.e. tag: bookmarks tag: #2024-06-01, you’ll get both the tourist destination but also the computer paragraph.
So actually the search in this particular case would most likely be: block: (2024-06 bookmarks) , which limits your search to a given block doing a free text search for the tag and the date part.
This is a very simplified example, but I hope it illustrates how you might need to tweak the search in order to not get false positives with the current implementation of the search engine of Obsidian. Note also that anything you can write in the search field, can also be used in an embedded query search code block (which I’m not going to talk any more about).
Using plain Dataview
When using Dataview and the standard DQL searches you either need to focus on the entire page or any given list or task item. This can be used both to our advantage and/or disadvantage. The disadvantage is that in the current form of the test document above you’re limited to the page context, to do searches like:
```dataview
LIST
FROM #bookmarks AND #2024-06-01
```
… or …
```dataview
LIST
FROM #bookmarks
WHERE any(map(tags, (t) => startswith(t, "#2024-06")))
```
Where the latter searches for a partial tag (if I got the syntax correct 
) In any case either of these searches would return just the note/page containing the matching result, and you wouldn’t now where in that file or which context it found the result.
This kind of block/content related searches are something Datacore, the successor of Dataview, which is in development would address, but which is currently not achieveable.
Using Dataviewjs
You could switch over to using javascript queries using ```dataviewjs, and read the entire content of the file, and implement the wanted searches using text searches. And there are various example spread out through the forum on how to read files section by section, or by paragraph.
This do however require some coding knowledge, and some fiddling with the script for each time you want to do a new search, so I’m not going to show examples of this just now.
Using Dataview in a list or task context
If we modify our test document to look like this:
- [b] https://somewhere.com/ #bookmarks #2025-06-01
- [b] https://dell.com My new fabulous computer #bookmarks #2025-07-02
- [I] Design app... I have an idea #message #2025-06-03
We would alter the context of the various bits and pieces. Using the above syntax in combination with a theme supporting extended task syntax, i.e. Minimal, this would look like:
Here I’ve used [b] to denote bookmarks (so I could’ve skipped the entire #bookmarks tag), and [I]` to denote an idea, and this would allow me to do a search like:
```dataview
TASK
WHERE status = "b"
AND contains(text, "2025-06")
```
Or a similar construct like above, i.e. any(map(tags, (t) => startswith("#2025-06"))), if I wanted to limit to just searching the tags.
The keypoint here is twofolded. Firstly since our information now is contained within a task item (and similar approach could be used with lists (with a few changes)) the query is made towards or within that single item, and the result we’re shown is just the items which matches our queries. So no false positives. Secondly, since this is a task query we’re keeping the option of clicking on the search result to go back to where the task was defined (just as in an ordinary search).
On a more visual note, I also find these decorated task to be more pleasing to the eye and easier to locate within a note due to the main categorisation done by assigning a given status (and thusly icon) to the task.
If you opt for just using list items, you loose the link back from the items returned from your query, and you’ll need to add some more syntax stuff into the query. So the similar query without the [...] parts in your documents would look something like:
```dataview
LIST item.text
FLATTEN file.lists as item
WHERE contains(item.tags, "#bookmarks")
AND contains(item.text, "2025-06")
```
Summary
So, where does that leave us regarding your original request? You could opt for doing plain searches and somewhat get your wanted result with the documents in their current form, but this will require fine tuning of the searches in order to avoid false positives.
From my point of view, you’d be better of switching your documents to become tasks, and start using Dataview TASK queries, as that would allow you to automatically target any given task with your query parameters.
If you’re patient enough, you could also opt for waiting for Datacore and rely on their improved block/paragraph handling. Something similar might also be implemented in a future version of Obsidian when their database view stuff is added.
