Does the blog live on my domain?

Yes. The customer-facing blog is installed on the customer's own domain through a lightweight runtime that connects to the publishing and rendering system.

Is this only an article generator?

No. The platform combines content generation, product context, publishing, server-rendered output, structured data and AI-readable endpoints for discovery.

What makes it ready for answer engines?

Published content can expose clean HTML, JSON-LD, Markdown mirrors, RAG JSON manifests, llms.txt files and crawler-governance signals.

Next-gen publishing for customer-domain blogs

Own-domain AI blog engine for search and answer engines.

Q: Can customers test it for free?

Yes. Customers can start with a free test to see the registration, workspace, content workflow and publishing model before committing to a rollout.

BlendScribe gives companies a free test of an own-domain AI blog service: business context goes in, reviewed articles and AI-readable publishing outputs come out.

Start free test See the engine

Domain-native blogThe public surface stays attached to the customer's own site.

AI plus reviewDrafts are generated from business context and approved before publishing.

Machine sourcesHTML, schema, Markdown and RAG outputs stay aligned.

BlendCustomer contextDomain, language, products and offer facts.

ScribeEditorial engineDrafts, structure, metadata and review.

RenderOwned-domain pagesServer HTML, schema and internal links.

ExposeAI-readable sourcesMarkdown, RAG JSON and discovery files.

Server-rendered HTML JSON-LD graph Markdown Mirror RAG JSON llms.txt

Live publishing surfaces

Domain scan context Product-aware article drafts Editorial review before publish Server-rendered HTML JSON-LD graph Markdown Mirror RAG JSON chunks llms.txt discovery robots.json policy Domain profile identity Domain scan context Product-aware article drafts Editorial review before publish Server-rendered HTML JSON-LD graph Markdown Mirror RAG JSON chunks llms.txt discovery robots.json policy Domain profile identity

RuntimeServer-rendered HTML for visitors and crawlers

InstallExisting-site blog launch without a frontend rebuild

DiscoverySearch and AI-readable sources stay aligned

Free testTry the customer workspace before rollout

Why BlendScribe

A full publishing engine, not a bulk article shortcut.

The service combines a customer workspace, site scan, AI-assisted drafting, editorial review, own-domain rendering and machine-readable outputs. Customers can test the flow first, then decide how to roll it into their website.

Context-first generation

BlendScribe starts from domain scan data, products, categories, language and business facts before a draft is created. The article is connected to the real offer instead of being a detached generic text.

Search-ready HTML

Server-rendered pages expose primary copy, internal links, canonical metadata and JSON-LD before enhancement scripts run.

Answer-engine sources

Markdown, RAG JSON, llms.txt and policy files give assistants cleaner material than scraped page fragments.

Editor and preview loop

Operators can work through the draft, metadata, article design and public output before publishing to the customer domain.

Built for existing websites

The blog runtime can add a native publishing surface to an existing site without asking the customer to rebuild the whole frontend.

How it works

A small install connects the customer site to the publishing workflow.

The business sees a normal domain-native blog. The operator gets a focused workspace for context, drafts, review and publishing. Search and answer engines receive cleaner source material behind the same public content.

Install a small PHP blog runtime on the customer domain. Add business context, generate and approve articles, then publish a public blog that feels native to the existing site.

Customer workspace

Brand, domain, language, products and publishing preferences stay scoped to one customer account.

Site install

A lightweight runtime adds the blog surface to the existing customer domain.

Content workspace

Drafts use product context, templates, metadata, FAQ blocks and internal-link signals.

Public renderer

The blog is served as crawlable HTML with canonical metadata and structured data.

Machine sources

Clean content mirrors and manifests expose the same approved material to machines.

Content operations

From context to useful published pages.

The workflow stays deliberately small: blend context, generate a structured draft, review the public output, then publish it for visitors, search engines and answer engines.

Blend the context

Start from a domain, products, categories, language and brand facts so articles are tied to the real offer.

Generate with structure

Create drafts with headings, summaries, FAQ candidates, product links and metadata prompts baked into the flow.

Review the rendered page

Inspect the final article surface, schema, internal links and discovery endpoints before publishing.

Publish everywhere needed

The same approved content becomes HTML for visitors and clean source material for search and AI systems.

Machine-readable content

The blog gives search and answer engines clean source material.

The product does not stop at generating text. Approved content can be served as human-readable pages and as structured source material that crawlers and assistants can parse with less guesswork.

/article

Server-rendered article HTML with canonical metadata, Open Graph and JSON-LD graph nodes.

Human surface

?md=1

Markdown Mirror for a clean article source with front matter, token estimate and content hash.

Agent source

?rag=1

Per-article JSON projection with heading-aware chunks for ingestion pipelines.

RAG ready

/rag.json

Site-wide manifest for change detection, filtering and corpus sync.

Manifest

/llms.txt

Curated Markdown index that explains the site and points assistants to important resources.

AI discovery

/.well-known/domain-profile.json

Canonical brand and software identity profile for answer engines and semantic extractors.

Identity

/robots.json

Structured crawler rules driven by the selected workspace policy.

Policy

Operating principles

Built for the constraints of real customer sites.

Modernity here means fewer moving parts, clearer output formats and less client-side fragility. The core page, metadata and links are available before any enhancement script runs.

SSR

Crawlable by default

Primary copy, links and schema exist in the initial HTML. JavaScript only enhances the interface.

CUS

Customer-safe publishing

Customer domains, settings and content operations stay isolated from each other.

CFG

Brand-ready foundation

Brand and domain values are configurable, so future naming changes stay manageable.

Trust model

The product surface makes the workflow inspectable.

Teams can review drafts, rendered pages, structured data and machine-readable content sources before the public article becomes part of the customer domain.

Clear sections

Sections are written as self-contained idea blocks so people can scan them and machines can extract them without losing context.

Connected entities

Organization, WebSite, WebPage, SoftwareApplication and FAQ nodes share stable identifiers in the server-rendered structured data.

TXT

Search and AI discovery

Public machine-readable resources help crawlers and assistants understand the approved content library.

Questions buyers ask

Clear answers before the first sales call.

Does the blog live on the customer's own domain?

Yes. The public blog is designed to be installed on the customer domain through a lightweight runtime, while the publishing system handles rendering and content operations.

Is this just an AI article generator?

No. Generation is only one step. The product also handles product context, metadata, public rendering, customer-domain routing, machine-readable mirrors and crawler rules.

Can the output be used by AI assistants?

Yes. Public articles can expose Markdown mirrors, RAG JSON projections, site-wide manifests and llms.txt discovery files so assistants can ingest the content cleanly.

Does this require rebuilding the customer's website?

No. The install model is meant to add the blog surface to an existing customer domain without forcing a full frontend rebuild.

Can customers test it for free?

Yes. The free test lets a customer register, enter the workspace and see the publishing flow before committing to a broader rollout.

How do the public blog pages stay fast?

The public surfaces are server-rendered, the core content and metadata are available in the initial HTML, and enhancement scripts stay small.

Who reviews the content before publishing?

The workflow is designed for operator review. Drafts, metadata, article layout and discovery outputs can be checked before content is published.

Next step

Turn customer context into an AI-readable publishing hub.

Start with a free test, connect one customer domain, blend the business context, then publish content that works for visitors, search engines and answer engines from the same source.

Start free test Ask a question