Update to RedirHub

{
  "description": "Plan and run a website migration with RedirHub — collect the old URLs, map each one to its new URL, import the 301 redirects as a reviewed dry run, check the old domain's DNS, and verify after launch. Use when someone is moving a site to a new domain, platform or URL structure, retiring a domain, or asks how to avoid broken links and lost SEO during a migration.",
  "included_files": [],
  "name": "website-migration",
  "skill_md_contents": "---\nname: website-migration\ndescription: Plan and run a website migration with RedirHub — collect the old URLs, map each one to its new URL, import the 301 redirects as a reviewed dry run, check the old domain's DNS, and verify after launch. Use when someone is moving a site to a new domain, platform or URL structure, retiring a domain, or asks how to avoid broken links and lost SEO during a migration.\n---\n\n# Website migration with RedirHub\n\nGoal: every old URL that had traffic or links lands on the right new page with a permanent redirect, and nothing changes in the user's workspace until they have seen and approved it.\n\nWork through the steps in order. Keep the user in the loop at each checkpoint marked **Confirm**.\n\n## 1. Scope the move\n\nAsk only what you don't already know:\n\n- Old domain(s) and new domain(s), e.g. `old-shop.com` → `www.newshop.com`.\n- Is the path structure changing, or only the domain? If only the domain changes, one domain redirect with path forwarding may be enough (see step 3a).\n- Where the old URLs come from: a sitemap, a CMS export, a CSV/spreadsheet, an analytics export, or a pasted list.\n\nCall `get-workspace` to confirm which workspace you are working in, and `list-hosts` to see whether the old domain is already connected.\n\n## 2. Build the URL map\n\n1. Collect the old URLs from what the user provides. Normalize them: drop the protocol, keep host + path (`old-shop.com/products/blue-mug`), keep query strings only when they select different content.\n2. Map each old URL to a new URL:\n   - Apply the user's rules first (e.g. `/blog/YYYY/MM/slug` → `/blog/slug`, `/products/` → `/shop/`).\n   - Match remaining pages by slug or title.\n   - Pages with no equivalent go to the closest parent page (category, section), never all to the home page.\n3. Flag for the user, as a short list:\n   - Old URLs with no confident match.\n   - Many old URLs pointing to one new URL (can be fine, but say so).\n   - Chains or loops (A → B while B → C, or A → A).\n\n**Confirm** the map with the user. Show counts and the flagged rows, not every row.\n\n## 3. Create the redirects\n\n### 3a. Domain-only move\n\nIf only the domain changes and paths stay the same, use `create-redirect` on the old domain with `type: \"301\"`, `forward_path: true` and `forward_query: true`. One record covers every path.\n\n### 3b. Path changes (the usual case)\n\nUse `bulk-import` with one row per old URL:\n\n```json\n{ \"url\": \"old-shop.com/products/blue-mug\", \"destination\": \"https://www.newshop.com/shop/blue-mug\", \"handler\": \"migration\", \"type\": \"301\" }\n```\n\n1. Run it as a dry run first (the default). Report `valid`, `invalid` and the `errors`, and fix the invalid rows with the user.\n2. `mode: \"create\"` (default) skips old URLs that already have a record. Use `mode: \"upsert\"` only when the user wants existing records replaced; it needs the `confirmation_token` from the dry run with the same rows.\n3. Up to about 5,000 rows per call; split larger maps into batches and keep a running total.\n4. **Confirm**, then call again with `dry_run: false`.\n\nUse 301 (permanent) for migrations. Use 302 or 307 only if the user says the move is temporary.\n\n## 4. Point the old domain at RedirHub\n\nRedirects only work once the old domain's DNS points to RedirHub.\n\n1. If the domain is not connected yet, `connect-host` it.\n2. Call `check-host-dns` and tell the user exactly which record to add (CNAME or A + TXT, name and value) at their DNS provider. Do not guess records; use the ones the tool returns.\n3. After they change DNS, `refresh-host` to re-check. HTTPS for the domain is issued automatically once DNS is correct; `get-host` shows its state.\n\nWarn the user that changing DNS moves all traffic for that host to the redirects, so the new site must already be live.\n\n## 5. Verify after launch\n\n1. `count-links` with `handler: \"migration\"` (and `dns_correct: false`) to confirm every record exists and none is waiting on DNS.\n2. Spot-check a few important old URLs with `get-link`.\n3. After traffic starts, use `get-access-logs` (optionally `bot_free: true`) and `get-stats` to see which old URLs are being hit. Requests to old paths with no record mean a missing mapping: add them with `create-redirect` or another small `bulk-import`.\n4. Suggest the user keep the redirects in place for at least a year, and update internal links and the sitemap on the new site to the new URLs.\n\n## Rules\n\n- Never write to the workspace without a dry run the user has seen. `bulk-import`, `bulk-update-links` and `bulk-delete-links` all dry-run by default; keep it that way until the user confirms.\n- Never delete existing links during a migration unless the user explicitly asks; deletions are irreversible.\n- Do not invent DNS records, URLs or counts. Report what the tools return.\n- If a tool reports a plan or link limit, tell the user plainly and stop; do not split work to get around it.\n"
}