[nicolasiscoding]

What changed and why

Indexability fixes from the docs SEO audit, plus title/H1/intro rewrites for pages that already get impressions for specific queries.

• static/_headers (new): every markdown copy /docs/<path>.md now sends Link: <https://docs.turbodocx.com/docs/<path>>; rel="canonical"; /docs.md points at /docs. One splat rule covers all copies (Cloudflare Pages allows 100 header rules, and there are more copies than that).
• Sitemap lastmod: lastmod: 'date' in the sitemap preset options, and fetch-depth: 0 on the CI checkout so dates come from each page's last commit (this also fixes "Last updated" dates, which were the build date with the shallow clone).
• BreadcrumbList JSON-LD: new src/theme/DocBreadcrumbs/StructuredData wrapper normalizes breadcrumb hrefs with Docusaurus' own applyTrailingSlash, so category index pages (docs home, Wrike, SDKs, Embedded signing and others) no longer list trailing-slash URLs that 308.
• Agent skills page: removed the related link to the unlisted (noindex) TurboPartner JavaScript page. No other indexed page links to an unlisted page.
• Fireflies page: the audit found two NUL characters in the production HTML, in the TOC entry for the emoji-led heading "How to Configure Fireflies in Settings". I removed the emoji from that heading (the heading anchor changes from #-how-to-... to #how-to-...; nothing in docs, the app or www links to it). This does not fix the NUL problem. See "Not verified".
• DOC-2 titles: rewrote title, H1 and opening paragraph, and added a short summary paragraph. sidebar_label keeps each page's existing sidebar/breadcrumb label. No file renames, so no URL changes.

Ticket checklist

DOC-1 (#253) Remove duplicate URLs

• List every %20 URL Search Console recorded and map it to its hyphen URL: 51 distinct URLs (54 with fragment variants) from the page-level and query+page tables. All 51 return 301 in one hop to a 200 hyphen URL on production (curl, 2026-10-24).
• 301 redirects from %20 forms: already in place from the dashed-URL rename; none missing, so no _redirects change.
• Canonicals use hyphen forms (checked live on hub and leaf pages); sitemap has zero %20 URLs (live and preview).
• Internal links: no links with spaces or %20 in docs/, src/, sidebars or the root JSON configs (only a commented-out line in DocChat.jsx).
• Audit extras: .md canonical header, sitemap lastmod, breadcrumb trailing slashes, unlisted-page link.
• Audit extra: Fireflies control characters. Not fixed. The NULs are a build-time issue that moves between pages from build to build (details below).
• Resubmit the sitemap and request indexing for top hyphen URLs in Search Console: owner action (no Search Console API access today).

DOC-2 (#254) Title and meta rewrite

• "scim provisioning" → SCIM-Provisioning: title "SCIM Provisioning: Automate User Accounts", H1 "SCIM Provisioning", summary, plus an example SCIM 2.0 POST /Users request (fields and the 201 response checked against product source).
• "pipeline connectors" + "private cloud connector" → Cloud-Connectors (both queries land on this one page): title "Pipeline Connectors: Private Cloud Connector", H1 adds "(Enterprise)". No code example since connectors are set up with our team.
• Not done (reverted in review). "fireflies api" → Fireflies: the product marks Fireflies as coming soon (comingSoon: true in src/components/TranscriptProviders/index.tsx, and a "This integration is planned" placeholder in src/components/ChangeResourceDialog/index.tsx on RapidDocxFrontEnd master and staging). The client code has not been merged to the product. The rewrite's title "Fireflies API Integration" and its new claims (connects through the Fireflies API, read-only access, pick Fireflies as a transcript source) are not backed by shipped code, so the title, H1, description, intro and keywords are back to their develop versions. Only the emoji-free heading is kept. See owner question 1.
• Partial. "custom signature appearance api" → How-to-Configure-Signature-Appearance: "custom signature appearance" is now in the title, the H1 ("Custom Signature Appearance in TurboSign") and the intro, but "api" is not in the title or H1. The only API is the unlisted TurboPartner preferences endpoint, so a title like "... API" would promise something the public docs don't offer. The full phrase waits on owner question 2. The summary says the settings apply to every new request, including ones sent through the TurboSign API, with no per-request options. No code example: see owner question 2. Also replaced the page's existing em-dashes.
• "embedded signing" → already had the phrase in title, H1 and first sentence. Light touch only: title tag "Embedded Signing: Sign Inside Your Own App" and a description shortened from about 220 to under 160 characters. The setup page (/TurboSign/how-to-enable-embedded-signing) also draws this query and already has the phrase in its title and H1; left unchanged.
• Position check after 4 to 6 weeks: post-release.

Part of #253
Part of #254
Closes #259

Verification (actually run)

• CI build passed, including the postbuild markdown-twin checks, and the post-deploy check (125 twin and llms URLs, 0 failing) on both preview builds.
• On the preview (https://96db1d80.turbodocx-docs.pages.dev (checks run on the previous build https://44b364a9.turbodocx-docs.pages.dev; only summary labels changed since)):
  • curl -I on /docs.md, /docs/SDKs.md, /docs/API/delete-webhook.md, /docs/Integrations/Wrike/field-mapping.md, /docs/TurboSign/embedded-signing.md and the signature-appearance twin: each returns 200 text/markdown with the expected Link canonical. HTML pages get no Link header.
  • BreadcrumbList JSON-LD on /docs, /docs/Integrations/Wrike, /docs/SDKs and two leaf pages: all items are slash-less.
  • sitemap.xml: 122 URLs, 122 <lastmod> values, 12 distinct dates (real git dates), zero %20.
  • Scanned all 122 sitemap pages on the preview and on production for NUL characters, trailing-slash breadcrumb items and %20 canonicals. Breadcrumbs: production has trailing-slash items on the Wrike and SDKs hub pages and their children; the preview has none. %20 canonicals: none on either. NULs: see below.
  • New <title>, H1, meta description and canonical on all five DOC-2 pages; Fireflies sidebar label unchanged.
• No em-dashes added (grep on the diff).
• Search numbers come from the Google Search Console mirror in our analytics warehouse (data through 2026-10-21); the direct Search Console API was unavailable today.

Independent review (2026-10-24)

• Re-curled all 32 distinct %20 docs URLs in the Search Console mirror (query+page table, fragments stripped): each is one 301 to a 200 hyphen URL. The only signature-appearance variants in the data are the How to/How-to forms, so no extra redirect is needed.
• Query to page mapping (mirror, since 2026-07-01): "pipeline connectors" and "private cloud connector" land only on Cloud Connectors, so its retitle does not compete with the pipelines overview. "embedded signing" lands mostly on how-to-enable-embedded-signing.
• Checked the SCIM example against scim-users (primary email or first email, externalId, 201 on create) and the signature-appearance "applies to API requests too" line against PDFSignatureUtility.ts (org preferences read at stamping time). Both are accurate.
• Smoothed the Cloud Connectors intro (dropped a repeated "Cloud connector").
• Note: src/theme/DocBreadcrumbs/StructuredData imports @docusaurus/utils-common, which is not a direct dependency (it resolves through hoisting from @docusaurus/core). Build passes; worth adding to package.json if a future dependency change unhoists it.
• CI run 40122538712 passed after the review push; preview https://c05772f9.turbodocx-docs.pages.dev shows Fireflies back to "Fireflies AI Integration", the new Cloud Connectors intro, and the .md Link canonical.

Not verified

• Production behaviour after merge (the same checks should be re-run on docs.turbodocx.com).
• NUL characters in built HTML (not fixed). The source files have no control characters. Production has a NUL on /docs/SDKs/webhooks (inside a code-block comment, # optional \x00— defaults to ...) and had two on Fireflies. The preview build has zero on Fireflies but has NULs on six other pages: /docs, /docs/Integrations/Wrike/signature-workflow, /docs/Pipelines/Creating-an-E-Signature-Pipeline, /docs/TurboQuote/Bulk-Importing-from-a-Spreadsheet, /docs/TurboSign/API-Signatures and /docs/TurboSign/Managing-Your-Signatures, mostly just before the zero-width space in heading hash-link anchors. The pages affected change from build to build, which points at the build pipeline (SSR or HTML minification) rather than content. It needs its own investigation; the Fireflies heading edit is only cosmetic.
• Search impact: needs 4 to 6 weeks after release.

Overlap with open PRs

• docs(sdks): publish the Ruby SDK docs #246 also edits docs/SDKs/agent-skills.md (the skills table near the top); this PR only removes one line in "Related" at the bottom. No conflict expected. Em-dashes already in that file were left alone to avoid conflicts.
• No other open PR touches these files.

Owner questions

1. Fireflies: the whole existing Fireflies page (develop) describes setup steps for an integration the product shows as coming soon. Should the page be marked coming soon, unlisted, or left until the feature ships? We should not chase "fireflies api" until this is settled.
2. The only programmatic way to set signature appearance is the TurboPartner organization preferences endpoint (hideSignatureOutline, hideSignatureHash, lockedFieldsBackground), and the TurboPartner pages are unlisted. Should the signature appearance page document that API, with a code example? If so, should the TurboPartner pages become indexable?
3. Search Console: please resubmit sitemap.xml and request indexing for the top hyphen URLs, since %20 URLs were still drawing impressions through 2026-10-19.
4. Cloud Connectors now targets both "pipeline connectors" and "private cloud connector" in one title. OK, or would you rather pick one?