@seoagent-official/seoagent 1.117.1 → 1.117.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.117.1",
+  "version": "1.117.3",
   "description": "The persistent AI SEO agent for Claude Code. Audits, keyword strategy, briefs, articles, real product screenshots from your repo, and the autopilot loop (cloud detects → CLI executes → ack closes) — other SEO tools write the prompt, SEOAgent runs it.",
   "type": "module",
   "bin": {

package/skills/references/inbox.md

@@ -39,7 +39,7 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 
 - `Read` it. **Check `source:` in the frontmatter first — it changes what already happened.**
   - **`source: repo`** — a *suggestion* for a page that lives in this repo. Nothing has been changed: the page is live and the cloud has not marked it pruned. The frontmatter has `slug` and `page_url`; the body has the 90-day Search Console numbers behind it. The cloud cannot see inbound internal links, so **search the repo for links to the page's path before anything else — any inbound link means decline** (`--failed --reason "kept; linked from <page>"`). Also decline when the page earns its place off-search (docs, changelog, emails). If a stronger page covers the topic, a 301 to it beats a bare deletion. A decline is remembered; the page is not proposed again.
-  - **`owner_approved: true`** (with `source: repo`) — the owner already said yes in Slack or on the dashboard. Do not ask again, and **do not decline because other pages link to it: do the whole job in one change.** (1) Find every internal link to the page — content, components, nav/footer config, hand-kept sitemaps, related-links data. (2) Repoint each to the replacement: `replacement_url` in the frontmatter (SEOAgent named it when it asked the owner), else the closest parent page that exists, else `/`; remove a link only when no sensible target exists. (3) Add a permanent 301 from the old path to it the framework's native way (Next.js `redirects()` in `next.config.*`, or the `middleware`/`vercel.json` the site already uses; Netlify/Cloudflare `_redirects`; Astro `redirects`; Hugo `aliases`; add the standard one if none exists). (4) Delete the page. (5) Name all of it in your summary: the page removed, each file whose links changed and to where, the redirect and its file. Decline only when the page's source or a redirect mechanism cannot be found. The file's **Do the whole job** section has the same steps. Without `owner_approved`, everything above stands.
+  - **`owner_approved: true`** (with `source: repo`) — the owner already said yes in Slack or on the dashboard. Do not ask again, and **do not decline because other pages link to it: do the whole job in one change.** (1) Find every internal link to the page — content, components, nav/footer config, hand-kept sitemaps, related-links data. (2) Repoint each to the replacement: `replacement_url` in the frontmatter (SEOAgent named it when it asked the owner), else the closest parent page that exists, else `/`; remove a link only when no sensible target exists. (3) Add a permanent 301 from the old path to it the framework's native way (Next.js `redirects()` in `next.config.*`, or the `middleware`/`vercel.json` the site already uses; Netlify/Cloudflare `_redirects`; Astro `redirects`; Hugo `aliases`; add the standard one if none exists). (4) Delete the page. Leave `llms.txt` and `.well-known/okf/` alone: `seoagent sync` regenerates both and drops the page once its source is gone or the 301 is in place, so a hand edit there is overwritten. (5) Name all of it in your summary: the page removed, each file whose links changed and to where, the redirect and its file. Decline only when the page's source or a redirect mechanism cannot be found. The file's **Do the whole job** section has the same steps. Without `owner_approved`, everything above stands.
   - **No `source`** — a legacy cull from a cloud-published article: the cloud already archived it and serves 410. The frontmatter has `action_id`, `article_id`, `slug`, and `cms_type`; remove the leftover file.
 - **Find the local file** that corresponds to the article. Look under `content/`, `src/content/`, `app/blog/`, `posts/`, `pages/blog/`, or wherever this project's articles live. Match by slug first, then by URL path. If you can't find an exact match, ask the user before doing anything destructive.
 - **Confirm with the user once per session** before deleting the first article. Show the title, slug, and the file path you intend to delete. After they confirm, proceed for the rest without re-prompting unless something looks ambiguous.