How BirchSeek works

BirchSeek reads your Search Console for the queries you nearly win. Page two is the core of the list: positions 11 to 20, measured over the last 30 days. A second pass over 90 days adds the demand a page already winning in the top ten attracts but cannot serve from one article - those sibling queries run from 11 down to 30, whether they sit on that same page or are close relatives of it elsewhere on your site.

Search Console is not the only source. The model proposes further phrases from your brand context, which is what a project with no Search Console property gets instead. Every Search Console row is scored 0 to 100 from its impressions and its distance from page one, and from nothing else: the click-through rate is stored beside the row and no scorer reads it. A model then re-ranks the whole list, weighing demand, proximity to page one, weak competition, fit and novelty. You see the query, your current position, its impressions, the score, and the model's one-line reason on the rows it gave one for.

Every factual claim gets its own numbered card in a rail beside the draft: the claim sentence, the URL, a status, and the excerpt the writer says supports it where the writer wrote one - that field is optional. The rail's header counts them: 14 claims, 13 sourced. Verified means a fetch reached that page and a test confirmed the claim there, and the record says which. Three tests run, but they resolve to four different facts: the writer's excerpt was found in the page's text; or no excerpt was written, so the claim's own wording was found there instead; or a passage of the page overlapped closely enough to pass; or a model read the page and called the claim supported. Only the first two locate anything on the page, and only the first locates an excerpt. Amber when nothing confirmed it, red when the page could not be read at all. A claim whose source does not check out holds the draft in the review inbox instead of your approval queue, flagged, until you cut it or send the draft back.

A quality score sits beside the citations, over five dimensions: humanity (an AI-pattern lint for banned phrases and repetition), specificity, structure balance, readability, and SEO (keyword coverage, heading structure, meta lengths).

You read it in a publication-grade preview, edit the markdown inline, and set the title tag, meta description, and FAQ pairs. Approve it, or request a new draft with notes.

An approved draft moves to Ready to publish, where you pick the target and confirm the options.

For GitHub, BirchSeek writes the MDX file with your frontmatter, branch, and path, then opens a pull request: preview deploys run and you merge when ready. For WordPress, Ghost, Webflow, Shopify, Wix, Notion and GoHighLevel, it creates a draft over the official APIs and you publish from your CMS. For webhooks, it delivers a signed JSON payload and shows you the receipt.

By default every publish to your own site ends with a Sources list: each verified claim, then a link to the page it was checked against. It is built once, before any connector sees it, so the committed MDX file, the CMS draft and the webhook's markdown all carry the same block, and it lists nothing that was not verified. One project setting, append_sources_section, switches it off for a site that prints its own reference list; there is no screen for it yet, so it travels in the settings object on a PATCH to the project. An off-domain placement builds its own copy and that one is not yours to switch off. A syndicated copy on dev.to, Hashnode or Medium carries the block too, under a canonical link back to your page, and the setting does not reach it: those three platforms have no citation field, so the body is the only place the evidence can travel.