Pages

Ask for a page of your site in brand chat and daoco writes it, then saves it as a durable artifact: a title, a page type, a URL slug, the markdown body, search metadata, and a version history. It opens in a Page panel beside the chat that survives a refresh. The panel opens on the page itself. Details holds publication, search metadata, the pages daoco reports auditing, and the history. When a thread wrote or imported more than one page, the bar at the top of the panel moves between them. This page says “article” for any saved page. A blog post is one type among seven.

​

Page types

The type decides how the page is written. A comparison reads each alternative’s own site and says where your brand is the wrong choice. A product review leads with its verdict and invents no ratings or testing. An FAQ answers each question in its first sentence. Pages saved before types existed default to blog posts. Imports use the page address, title, and body to identify the type; you can ask daoco to change it. An article is not a social draft. Social drafts are shaped around platforms: one idea, a variant per channel, media, target accounts. An article is one body of markdown with one set of search metadata, so it lives in its own place with its own history.

​

Ask for an article

You can also type /write-page with a topic or a page type. Before it writes, it reads your Search Console queries when Search Console is connected and checks which pages rank for the question now, then writes one page and saves it. If a page in your library already answers the question, it revises that page instead of writing a second one. /page-to-site does the same and then prepares the page on your connected site for approval.

​

The Pages tab

Open Home, choose Website, and open the Pages tab. Every page the brand has is listed there with its title, type, when it was last updated, its word count, its version, and its publication state, such as PR open, Merged, not live yet, Published, or Not found on site. See Publication for what each one means. A linked page also shows when it was last checked and a Check now button. A page sent for sign-off shows that separately, as Awaiting sign-off, Changes requested, Approved, or Approved an older version. Once the library holds more than one type, chips above the list filter by type. The first time you open it, the tab offers to bring in what you already have. Enter your site’s address, for example yoursite.com, and choose Bring in my existing pages. Daoco finds the pages your site has (home, product, comparison, FAQ, case study, guide, and blog pages), saves each one here, and labels it with its type. Legal, login, and checkout pages are left out. If a page lands under the wrong type, ask Daoco in the thread to change it. New page lists the seven types. Write beside a type starts a thread that picks the topic from your brand context and current demand, writes the page, and saves it. If the last run finished without producing anything, the tab says so and links you to that thread. A personal brand sees this tab as Writing, without page types or suggestions. Its Bring in my published work runs the same import from wherever your work is published.

​

Suggested pages

Above the list, Suggested pages shows pages Daoco recommends writing, each with the question it answers, the type that fits, and the measurement behind it. Suggestions come from recorded findings: an AI visibility check that found a question answered from competitors’ pages with none of yours cited, or a Suggest pages run (/suggest-pages, the first step of /page-plan). That run reads your latest AI visibility check, your tracked rankings, and your page library, and records up to eight missing pages, skipping what your library already holds. It does not write them. Each question is listed once. When an AI visibility check and a Suggest pages run both find the same question, it is one suggestion, labeled with both. Dismissing or writing it clears it for both. Write it on a suggestion starts a thread that checks whether an existing page already covers the question, then writes and saves the page. Saving it takes the suggestion off the list and records which question the page was written for. Dismiss sets a suggestion aside; it stays dismissed when later checks measure the same gap, and Show dismissed lets you restore it. A suggestion taken on through a site fix also leaves the list.

​

How your pages are doing

Each published page shows what recorded checks say about it: how many AI answers in the latest AI visibility check cited that page, whether you are now cited on the question it was written for, and its position for a tracked keyword. A page no check has measured shows nothing, so a blank line never means zero. Check my pages runs the weekly SEO review as /check-pages: it checks your ranks, AI visibility, and Search Console when connected, re-audits your published pages, and records a fix for each one that is underperforming. Those fixes appear on the SEO tab. It does not prepare, rewrite, or publish anything. With an assistant’s Weekly AI visibility review on, the same loop runs every Thursday: it reports what earlier pages earned, then drafts the page for the biggest open gap.

​

Import existing articles

Ask “Import the existing articles from example.com/blog into my article library.” Daoco discovers article candidates through the site, sitemap, and linked feeds, then saves each readable article directly from its HTML. It converts the body to Markdown without asking a model to rewrite it. Source bylines and dates are recorded when present; missing dates are not guessed. The saved article holds the full extracted body. Chat and panel previews may be shortened; Show full article loads the saved body. Pages without an identifiable article body, unreadable pages, and articles exceeding the size limit are skipped with a reason rather than saved as partial copies. Discovery is bounded and reports when it cannot establish a complete inventory. Retrying an import reuses the article for that brand and canonical URL and preserves any edits you made. Older imports without extraction metadata are reported as unverified, not silently replaced. The final report links the saved articles and lists existing, skipped, or incomplete results. A page imported in full from its live address shows Published, because the import is the read that found it there. Edit it afterwards and it shows Live · newer edits not published. Older imports that recorded no source show Not checked yet until a publication check reads the page.

​

Writing against a real page

Give daoco a URL and it reads the page before it outlines. It crawls the page and uses what is actually there (the real headings, the real length, whether the page has a comparison table or an FAQ, what schema it carries) to decide what your article has to match, where it can go deeper, and what page one is missing. That is the difference between “write me a long article about email deliverability” and an article built to beat a specific page. Without a URL, daoco writes from your brand context and says so rather than implying research it did not do. The panel lists the pages daoco reports auditing for the brief, under a heading that says exactly that. It is the writer’s own account of what it read, not an independently verified record, and when nothing was reported the panel says so rather than leaving the space blank. Those audited pages are research provenance, not automatic article citations. A competing guide that helped shape the outline stays in the panel and does not appear in the article’s Sources section unless the article quotes it or uses it to support a factual claim. Sources that do support a claim remain in the article so readers can verify it.

​

What gets saved

​

Structure and schema markup

Each page type has a shape, and daoco checks the saved body against it: a comparison needs a table, an FAQ needs at least three question headings with an answer under each, a guide needs steps, a case study needs a measured result, a landing page needs a link for its next step. When something is missing, daoco is told as it saves so it can fix the page in the same turn, and the page panel lists what is missing. The panel also has the page’s Schema markup, built from the saved page: FAQPage with every question and answer for an FAQ, BlogPosting or Article for posts, guides, and case studies, and WebPage otherwise. A product review is not marked up as a Review, because that requires a rating and daoco does not invent one. Copy gives you the script block. When daoco puts a page into WordPress or Shopify, it sends the markup with it and tells you if the site removed it.

​

Sign-off

Ask daoco to send a page to named people for sign-off before it goes live (“send the comparison page to Sam for approval”). It uses the same reviews as other work. The review is linked to the saved page version. When daoco sends that page to a connected site, it checks that the review is approved and still matches the current page. Editing the page requires a new sign-off before publishing. This check is something daoco does, not a lock on your site: someone with access can still publish from WordPress or Shopify directly.

​

Revising

Ask for changes in the same thread (“tighten the opening”, “add a pricing section”, “retarget this at b2b email deliverability”) and daoco revises the article in place. Each content change appends a version; the panel shows the history. Pick a version from the version menu beside the page type, or from History under Details, to read it in full. The panel says which version you are reading and Back to latest returns to the current one. You can continue in the article’s chat thread. Ask “open a pull request for this article”, or type /page-pr, to send the saved article to your connected GitHub repository. You do not need to ask for another writing pass. See Connect GitHub for the approval flow. Every page appears under Website > Pages, drafts included. A published article opens its live page in a new tab; an article with an open pull request opens it; a draft opens the chat thread where it was written, which is where editing happens. Metadata-only edits are recorded as such, so “we rewrote it” and “we retitled it” are different entries.

​

Publication

Writing and publishing are tracked separately. An article carries a publication record that says where it lives and what has been confirmed there, and the label you see is derived from that record, never from anyone saying so. Publication states:

• Draft: no destination recorded.
• PR open: linked to an open pull request; nothing confirmed yet.
• Not checked yet: linked to a page or CMS record that has not been read.
• Not found on site: the last check found no page at the address (or no file on the deploy branch).
• Different on site: the page exists but does not match any saved version. Someone may have edited it on the site, or the link points at another page.
• Couldn’t check: the last check could not read the page or repository, for example because the site did not respond or GitHub is not connected.
• Merged, not live yet: the file is on the deploy branch, but the live page has not confirmed it. Usually the site has not deployed yet.
• Published: the live page carries the article. CMS records are not read directly; the page is the evidence.
• Live · newer edits not published: the live copy is an older version than the saved article.

Sign-off is shown separately from these states: a page can be approved and not live yet, or live without sign-off. The panel keeps the evidence: which check ran, when, whether it matched, and how much of the article it found. A check that could not reach the page never removes an earlier confirmation.

​

Indexing

Whether Google has the page is a third fact. With Google Search Console connected, Check indexing in the panel (or “is it indexed?” in chat) asks Google directly and records the verdict, coverage state, and last crawl on the article. A live page that is not indexed yet is normal for the first days after publishing.

​

Archiving and restoring

Articles you no longer want are archived, not deleted. Use Archive in the menu beside the page title, or ask in chat. Archived articles stay queryable and can be restored from the same menu.

​

Current limits

• Publishing goes through a connection. Pages are saved in daoco. daoco can propose a page as a pull request to a connected GitHub repository, which you merge, or put it into a self-hosted WordPress site or a Shopify store as a draft and publish it with your approval. On WordPress.com, Webflow, and Wix it uses whatever page tools that connection offers. Square is read-only for pages: daoco uses your catalog for facts and hands you the page to paste. It verifies publication by reading the repository and the live page; CMS records themselves are not read yet, so a CMS-published article is confirmed from its live page.
• No search volume or difficulty. /write-page reads Search Console impressions and positions when it is connected, and the pages ranking for the question now. It does not look up search volume or keyword difficulty, so demand it found on the web is described in words, not numbers. Without Search Console, the target query is inferred rather than measured, and Daoco says so instead of inventing numbers.
• One article per piece. Revise the article you have rather than asking for a second one on the same topic; the history is more useful than two drafts.