Website content lifecycle
42flows does not just generate an article and leave you to paste it somewhere. The website integration is meant to carry the work from idea to published URL.
The lifecycle has five steps:
- Connect the website. Give 42flows the right access for your stack.
- Read enough context. 42flows checks what the site can accept and where content should go.
- Publish the content. The article is sent to WordPress, Shopify, GitHub, Nuxt, or your webhook.
- Verify the page. 42flows checks whether the public URL is reachable after publishing.
- Improve or redeliver. If the platform supports updates, 42flows can send the work again or improve an existing page.
WordPress, Shopify, GitHub, Nuxt, or webhook access
Routes, blog target, repo files, or endpoint health
The content lands in the chosen website path
The public URL is checked after publish
Redeliver, update, or optimize where supported
What you can see
42flows tracks the work in customer-visible terms:
| Concept | What it means |
|---|---|
| Site connection | The website, store, repo, receiver, or webhook you connected. |
| Content plan | The topics and pages 42flows plans for the business. |
| Content request | One article or page 42flows is preparing to publish. |
| Published page | The final URL, delivery result, and verification status. |
| Activity history | A plain trail of what happened: connected, tested, published, verified, or needs attention. |
These are the concepts that matter to a customer. The internal database names do not matter and are not part of the public contract.
Connect
Each website path has a different setup step.
| Website path | What you do | What 42flows checks |
|---|---|---|
| WordPress | Create or approve WordPress publishing access. | REST access, post creation, SEO plugin compatibility, and companion plugin support. |
| Shopify | Connect the Shopify store. | Store access and blog publishing availability. |
| Nuxt Content via GitHub | Install the GitHub App and choose the repo/branch. | Repo access, content folder, package setup, and route fit. |
| Nuxt direct receiver | Install the Nuxt receiver package and set the receiver token. | Receiver health endpoint. |
| Webhook | Add one HTTPS endpoint and set the bearer token. | Signed ping request. |
If the business does not have a website, use Local ranking instead. That path starts from Google Business Profile and chat-based publishing support, not website publishing.
Read
42flows reads only what the integration needs.
| Website path | What may be read |
|---|---|
| WordPress | Posts, pages, SEO plugin state, and page structure needed for publishing or optimization. |
| Shopify | Store and blog availability for publishing articles. |
| GitHub/Nuxt Content | Repo files that explain how content is stored and routed. |
| Nuxt direct receiver | Receiver health and public page metadata. |
| Webhook | The endpoint's ping response. Your app owns its own content storage. |
Publish
When a new article is ready, 42flows sends it through the chosen path:
| Website path | What happens |
|---|---|
| WordPress | A post is created or updated by slug, with title, body, SEO fields, schema, category, and optional image. |
| Shopify | A Shopify blog article is created with title, body, tags, SEO fields, and optional image. |
| GitHub/Nuxt Content | A markdown content file, and optional assets, are committed to the selected repo branch. |
| Nuxt direct receiver | The receiver endpoint accepts the article content and metadata. |
| Webhook | Your endpoint receives markdown, HTML, metadata, schema data, and a slug. |
Public URL rules
GitHub and Nuxt Content sites need a predictable path from file to public URL. A common pattern is:
| Page type | Example URL |
|---|---|
| Blog article | /blog/my-article-slug |
| Problem page | /problem/my-article-slug |
| Comparison page | /compare/my-article-slug |
| Report page | /reports/my-article-slug |
| Picks page | /picks/my-article-slug |
If your site already uses a different route shape, 42flows should follow that instead of forcing a new one.
Redelivery and updates
Sometimes the same content needs to be sent again. The safest update rule is the slug or file path.
| Website path | Redelivery guidance |
|---|---|
| WordPress | The same slug updates the existing post instead of creating a duplicate. |
| Shopify | Use a clear article slug and check the Shopify blog before re-sending the same topic. |
| GitHub/Nuxt Content | The same file path can be updated in a new Git commit. |
| Nuxt direct receiver | The receiver should treat the slug/content path as the unique key. |
| Webhook | Your handler should upsert by article.slug so a re-send is safe. |
For custom websites, this is the most important rule: make your endpoint idempotent by slug.
Improving existing pages
Publishing a new article is different from improving a page that already exists.
| Website path | Existing-page improvement |
|---|---|
| WordPress | Strongest support. 42flows can read a page, propose targeted edits, apply approved changes, and restore a WordPress snapshot if needed. |
| GitHub/Nuxt markdown | Good fit when the page is stored as markdown in the repo. Changes are normal Git commits. |
| Shopify | Best treated as blog publishing unless a custom optimization workflow is agreed. |
| Nuxt direct receiver | Good for publishing new content; existing-page edits depend on the receiver and site structure. |
| Webhook | Your app owns existing-page edits unless you add a separate edit API. |
Verification
After publishing, 42flows can check the public URL. The result is meant to be understandable:
| Result | What it usually means |
|---|---|
| Verified | The page is reachable and shows the expected 42flows content marker. |
| Not found | The page is not live yet, the route is wrong, or the deployment has not finished. |
| Login or blocking issue | The page is behind auth or blocked from public crawlers. |
| Build or render issue | The deployed page shows a build/render problem. |
| Wrong page at that URL | The URL already belongs to a different page. |
| Stale cache | The old version is still being served. |
| Could not reach URL | The verifier could not connect to the page. |
Verification is strongest when the integration returns a public URL. For webhook sites, return the final postUrl whenever possible.
Removing or undoing content
42flows does not automatically delete published website content. If a page should come down, treat it as a deliberate support/customer decision.
For WordPress Page Optimizer changes, 42flows can restore the saved WordPress snapshot. For Git-backed sites, undoing a change should follow the normal Git and deploy workflow for that repo.