How I use Omnivore and Logseq for reading articles
Based on CombiningMinds's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Omnivore’s label-driven export enables a block-based pipeline into Logseq, reducing the friction of page-by-page exports.
Briefing
A block-based workflow is the key upgrade: Omnivore can export reading highlights and notes into Logseq as structured blocks, letting users tag, review, and move material into a Daily Journal without the “single-page” export friction that pushed the creator away from Readwise Reader. The practical payoff is a smoother pipeline from “save while reading” to “processed and searchable in a knowledge base,” especially when reading on mobile during travel.
The workflow starts with capturing articles. Using the Omnivore browser plugin, the user sends an article into an Omnivore inbox (for example, from Substack recommendations). Omnivore’s interface supports customizing how articles display, but the standout feature is in-reading annotation: highlights and notes can be exported to Logseq. Instead of exporting whole articles as separate pages, the user labels items inside Omnivore—specifically using a label like “Sent to Logseq”—then archives them so they leave the inbox.
On the Logseq side, the integration is configured to pull only labeled items by setting the Omnivore import filter type to Advanced. The user relies on Logseq’s Omnivore import page plus templates to standardize incoming data. Those templates create block structures with block properties such as the producer/source, tags, and links, and they format highlights as quote blocks (using a “greater than” markdown rendering). This matters because it distinguishes the author’s text from the user’s observations and keeps each imported item consistent enough to process quickly.
After import, the user performs a lightweight triage: add or adjust tags at the article level (e.g., adding “chronic pain” if needed), then move the processed content into a Daily Journal section. A “Content Block” separator in the Daily Journal acts as a staging area for external material, turning the workflow into a repeatable checklist: import from Omnivore → tag and review highlights → move into the Daily Journal. The result is a system for tracking what’s been processed versus what remains in the inbox.
Omnivore also supports additional capture channels that feed the same database: users can create an email address in their profile so newsletters can be sent directly to Omnivore, and they can send tweets/threads via “share via Omnivore,” which renders Twitter content into a readable format (with occasional missing tweets noted for long threads). The creator emphasizes that Omnivore is open source and free, and that development is moving quickly, including periodic feature drops.
Finally, the workflow is positioned as one component of a broader personal knowledge management approach tied to Logseq Mastery and “source-based writing.” The central idea is to keep large, return-worthy materials (books, PDFs, courses) organized as “Pages,” while treating smaller items (articles, videos, podcasts, tweets) as blocks in the Daily Journal—so the database stays lean, fast, and easy to search through consistent tagging and author-based retrieval.
Cornell Notes
Omnivore is used as a capture and annotation layer that exports reading highlights into Logseq as block-structured content. The workflow hinges on labeling items in Omnivore (e.g., “Sent to Logseq”), archiving them, and configuring Logseq’s Omnivore import to use an Advanced filter so only labeled items sync. Logseq templates then standardize imports with block properties (source/producer, tags, links) and render highlights as quote blocks, separating author text from user observations. After import, the user tags and triages content, then moves it into a Daily Journal for ongoing review. The approach matters because it avoids page-by-page export friction and turns reading into a repeatable, searchable pipeline.
Why does exporting highlights as blocks matter more than exporting articles as individual pages?
How does the “Sent to Logseq” label control what gets imported into Logseq?
What role do Logseq templates play in making imported reading usable?
What does the triage step look like after content arrives in Logseq?
How can new reading items enter Omnivore besides using the browser plugin?
How does this workflow fit into a broader knowledge management strategy?
Review Questions
- What specific mechanism ensures only selected Omnivore items sync into Logseq?
- How do Logseq templates change the way highlights appear and how does that affect later tagging?
- Why does the workflow move processed content into a Daily Journal instead of leaving it only in the import area?
Key Points
- 1
Omnivore’s label-driven export enables a block-based pipeline into Logseq, reducing the friction of page-by-page exports.
- 2
Capture reading with the Omnivore browser plugin, then apply a label like “Sent to Logseq” and archive items to clear the inbox.
- 3
Configure Logseq’s Omnivore import to use an Advanced filter so only labeled items sync.
- 4
Use Logseq import templates to standardize block properties (source/producer, tags, links) and render highlights as quote blocks for clear separation.
- 5
After import, triage by adjusting tags and then move content into a Daily Journal for ongoing review.
- 6
Feed Omnivore through multiple channels—newsletter email and “share via Omnivore” for tweets/threads—so the same workflow handles more than just web articles.