mirror of
https://github.com/mintlify/docs.git
synced 2026-09-14 13:35:46 +08:00
017d7c7377
* fix: reduce Vale false positives via vocab and config updates - Make English-word vocab entries case-insensitive so sentence-start capitalization and normal prose usage stop flagging (agents, rest, cursor, setup, endpoints, etc.) - Add vocab entries for filenames and code identifiers that appear in frontmatter and JSX contexts (docs.json, llms.txt, CLAUDE.md, etc.) - Ignore openapi frontmatter lines, filenames, JSX attributes, email addresses, and internal link targets via TokenIgnores - Skip inline code scope and indented code fences - Add Headings exceptions for proper nouns (Claude Code, GitHub Actions, Route 53, GA4, etc.) - Disable linting for the all-code vercel-json-generator snippet Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: resolve all Vale warnings and errors across docs Content fixes: - Reword sentences using 'will', first person, spaced em dashes, 'e.g.', Latin abbreviations, and hyphenated adverbs - Sentence-case headings that started with dotted filenames - Backtick literal API values instead of bolding them - Move periods inside quotation marks - Fix Oxford comma rule misfires by restructuring sentences False-positive suppression: - Vale toggles around example user questions, keyboard shortcut keys (Cmd+I), UI labels, and code samples in JSX contexts that Vale misparses - Exclude vale toggle comments from the brace Token/BlockIgnores so in-document commands actually reach Vale (the greedy brace pattern was also silently swallowing large regions; now lazy) - Vocab entries for code identifiers (internal_id, handleSubmit, etc.) - Per-file rule disables for component docs with dotted JSX names and files where link-target linting ignores in-document toggles Result: vale --minAlertLevel warning is clean repo-wide; only suggestion-level items (Passive, Semicolons, Acronyms) remain. mint broken-links passes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: correct WordList rule instead of degrading prose - Restore sentence-start "Email" in advanced-support; the rule now only flags hyphenated e-mail/E-mail forms - Restore the idiom "above all else"; the above->preceding swap now exempts "above all" Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: restore deliberate prose flagged by blunt rules - Restore spatial 'above the navbar' / 'above a page title' in custom-scripts; the above->preceding swap now exempts 'above the/a/an' - Restore the '= ...' in the react-components named-export example (the ellipsis is inside inline code) with an Ellipses toggle - Restore SLA phrasing 'will use commercially reasonable efforts' with a Will toggle - Restore the quoted developer question in the GEO guide intro with a FirstPerson toggle, matching the file's other example questions Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: remove WordList swaps that flag legitimate English - Drop tablet->device and firewalls->firewall rules; both words are correct in ordinary prose - Narrow touch->tap to UI-instruction phrasing (touch the/a) so 'keep in touch' and 'touch devices' stop flagging Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: reposition vale toggles to wrap whole blocks Toggle comments placed between list items split the lists (restarting ol numbering in deployments) and comments flush against tables risked breaking GFM table parsing. Wrap entire lists/tables with blank-line separation instead. Verified rendering with mint dev: single ol with two items, tables intact, no comments in visible DOM. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor: prune accept.txt to load-bearing entries Empirically removed 166 vocab entries (575 -> 409) whose removal causes no Vale flags across all 908 English pages: dictionary words that never needed listing (agents, setup, endpoints, webhooks, yaml), lowercase entries the speller already accepts, and filename entries made redundant by inline vale toggles. Kept every case-enforcing entry (API, JSON, GitHub, ...) so casing policy is unchanged, plus entries that double as capitalization exceptions for headings (mcp, md, auth, cursor, txt). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Update ai/mintlify-mcp.mdx * Update api/agent/v2/create-agent-job.mdx * chore: alphabetize Headings exceptions and accept.txt Case-insensitive sort, ignoring the (?i) prefix; also drops a duplicate Scala entry. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix: re-apply OxfordComma rewrite lost in branch merge Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: resolve Vale suggestions batch 1 (acronyms, semicolons, passive voice) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: resolve remaining Vale suggestions (passive voice batch 2) Rewrite ~90 passive constructions to active voice across deploy, guides, migration-services, and organize docs. Toggle the deliberate passive examples in the style-and-tone guide ('by zombies' test). Add axios/lodash vocab entries for a repositioned code example. vale . is now fully clean: 0 errors, 0 warnings, 0 suggestions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
231 lines
8.8 KiB
Plaintext
231 lines
8.8 KiB
Plaintext
---
|
|
title: "How to link documentation pages effectively"
|
|
sidebarTitle: "Linking"
|
|
description: "Create internal links, anchor links, and deep links in your documentation, and maintain link integrity with redirects and broken link checks."
|
|
keywords: ["documentation links", "internal links", "anchor links", "broken links", "deep linking", "cross-references"]
|
|
---
|
|
|
|
Links connect your documentation into a coherent system. They help users discover related content, navigate efficiently, and follow a logical path through complex topics. Poor links—vague anchor text, missing cross-references, broken URLs—make documentation harder to use and hurt SEO.
|
|
|
|
This guide covers how to create different types of links in Mintlify and how to maintain link integrity as your documentation grows.
|
|
|
|
## Internal links
|
|
|
|
Link to other pages in your documentation using root-relative paths. Root-relative paths start from the root of your documentation directory and work consistently regardless of where the linking page sits in your directory structure.
|
|
|
|
```mdx
|
|
- [Quickstart guide](/quickstart)
|
|
- [API overview](/api-playground/overview)
|
|
- [Custom components](/customize/react-components)
|
|
```
|
|
|
|
Mintlify resolves relative paths (`./` and `../`) based on the source file's location in your project directory. This works for links, images, and JSX elements like `<Card>` and `<a>` tags.
|
|
|
|
```mdx
|
|
- [Sibling page](./sibling-page)
|
|
- [Parent section page](../other-page)
|
|
```
|
|
|
|
For `index.mdx` files, relative paths resolve from the directory that contains the index file. For example, a `./setup` link in `guides/getting-started/index.mdx` resolves to `/guides/getting-started/setup`.
|
|
|
|
Links preserve fragments and query strings.
|
|
|
|
```mdx
|
|
[Setup instructions](./setup#step-1)
|
|
```
|
|
|
|
<Tip>
|
|
Root-relative paths (starting with `/`) perform better for internal links because they remain correct if you move the linking page to a different directory.
|
|
</Tip>
|
|
|
|
## Anchor links
|
|
|
|
Anchor links point to specific sections within a page. Every heading automatically generates an anchor based on its text.
|
|
|
|
### Link to headers on the same page
|
|
|
|
Reference headers on the current page using the hash symbol:
|
|
|
|
```mdx
|
|
[Jump to best practices](#best-practices)
|
|
```
|
|
|
|
### Link to headers on other pages
|
|
|
|
Combine the page path with the anchor:
|
|
|
|
```mdx
|
|
- [Customize your playground](/api-playground/overview#customize-your-playground)
|
|
- [Cards properties](/components/cards#properties)
|
|
```
|
|
|
|
### How Mintlify generates anchors
|
|
|
|
Mintlify automatically creates anchors from header text by converting to lowercase, replacing spaces with hyphens, and removing special characters.
|
|
|
|
| Header text | Generated anchor |
|
|
|---|---|
|
|
| `## Getting Started` | `#getting-started` |
|
|
| `### API Authentication` | `#api-authentication` |
|
|
| `#### Step 1: Install` | `#step-1-install` |
|
|
|
|
<Note>
|
|
Headers with the `noAnchor` prop do not generate anchor links. See [Format text](/create/text#disable-anchor-links) for details.
|
|
</Note>
|
|
|
|
### Custom anchor IDs
|
|
|
|
Override the auto-generated anchor for any heading by appending `{#custom-id}` to the header text:
|
|
|
|
```mdx
|
|
## Configuration options {#config}
|
|
```
|
|
|
|
This heading is reachable at `#config` instead of `#configuration-options`. Custom IDs keep anchor links stable when you update heading text—useful for headings you link to frequently. See [Format text](/create/text#custom-heading-ids) for more details.
|
|
|
|
## Deep links
|
|
|
|
Deep links point to specific states or locations within a page, not just the page itself.
|
|
|
|
### Accordion deep links
|
|
|
|
When a user opens an accordion, the URL hash updates to reflect the open state. Visiting a URL with that hash automatically opens and scrolls to the accordion.
|
|
|
|
By default, the hash derives from the accordion's `title`. Use the `id` property to set a custom hash:
|
|
|
|
```mdx
|
|
<Accordion title="Installation steps" id="install">
|
|
...
|
|
</Accordion>
|
|
```
|
|
|
|
This accordion is reachable at `#install` instead of the auto-generated `#installation-steps`. See [Accordions](/components/accordions) for more.
|
|
|
|
### API playground deep links
|
|
|
|
To open the API playground in a link, append `?playground=open` to any endpoint page URL:
|
|
|
|
```text
|
|
https://your-docs-url/endpoint-path?playground=open
|
|
```
|
|
|
|
The URL updates as users open or close the playground. Use playground deep links in support conversations or onboarding flows to send users directly to an endpoint's interactive playground. See [API playground](/api-playground/overview#parameter-anchor-links) for information on parameter anchor links.
|
|
|
|
## External links
|
|
|
|
When linking to external resources, write anchor text that makes the destination clear:
|
|
|
|
```mdx
|
|
See the [OpenAPI specification](https://swagger.io/specification/) in the Swagger documentation for details.
|
|
```
|
|
|
|
## Best practices
|
|
|
|
### Write descriptive anchor text
|
|
|
|
Anchor text should tell users where they're going before they click. Vague phrases like "click here" or "read more" are also weaker SEO signals than descriptive text.
|
|
|
|
<CodeGroup>
|
|
|
|
```mdx Good
|
|
See [Hidden pages](/organize/hidden-pages) for more information.
|
|
[Configure custom domains](/customize/custom-domain)
|
|
```
|
|
|
|
```mdx Avoid
|
|
[Click here](/api-playground/overview)
|
|
[Read more](/deploy/deployments)
|
|
[See this page](/customize/custom-domain)
|
|
```
|
|
|
|
</CodeGroup>
|
|
|
|
### Link prerequisites explicitly
|
|
|
|
When a page assumes prior steps, link to them at the top rather than assuming users find them:
|
|
|
|
```mdx
|
|
## Prerequisites
|
|
|
|
Before deploying your documentation, ensure you have:
|
|
|
|
- Completed the [quickstart guide](/quickstart)
|
|
- Configured your [custom domain](/customize/custom-domain)
|
|
- Set up [authentication](/deploy/authentication-setup) if needed
|
|
```
|
|
|
|
### Build topic clusters
|
|
|
|
Link related content together to help users—and search engines—understand how you organize your content:
|
|
|
|
```mdx
|
|
## Related topics
|
|
|
|
- [API authentication](/api-playground/overview#authentication)
|
|
- [Adding SDK examples](/api-playground/adding-sdk-examples)
|
|
- [Managing page visibility](/api-playground/managing-page-visibility)
|
|
```
|
|
|
|
### Check for broken links
|
|
|
|
Run the Mintlify CLI before publishing to catch broken internal and external links:
|
|
|
|
```bash
|
|
mint broken-links
|
|
```
|
|
|
|
### Update links when reorganizing
|
|
|
|
When moving or renaming pages:
|
|
|
|
1. Update the page path in your navigation configuration.
|
|
2. Configure redirects from the old path to the new path.
|
|
3. Search your documentation for references to the old path.
|
|
4. Update all internal links to use the new path.
|
|
5. Run `mint broken-links` to verify.
|
|
|
|
### Use redirects for moved content
|
|
|
|
When permanently moving content, add redirects to prevent broken links for users who have bookmarked or shared old URLs.
|
|
|
|
```json
|
|
{
|
|
"redirects": [
|
|
{
|
|
"source": "/old-path",
|
|
"destination": "/new-path"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
See [Redirects](/create/redirects) for more information.
|
|
|
|
## Frequently asked questions
|
|
|
|
<AccordionGroup>
|
|
<Accordion title="Should I use root-relative or absolute URLs for internal links?">
|
|
Root-relative paths (starting with `/`) are the most common choice for internal links in Mintlify. They work consistently regardless of where the linking page sits in your directory, and they don't break if your documentation domain changes. Absolute URLs for internal links create unnecessary brittleness.
|
|
|
|
You can use relative paths (`./` and `../`), but because they resolve based on the source file's location they may break more frequently.
|
|
</Accordion>
|
|
|
|
<Accordion title="How do I keep anchor links stable when I update headings?">
|
|
Use custom anchor IDs for headings you link to frequently. Appending `{#custom-id}` to a heading decouples the anchor from the heading text, so you can update the heading text without breaking any links that point to it. This is especially useful for headings in high-traffic reference sections where the text may need refinement over time.
|
|
</Accordion>
|
|
|
|
<Accordion title="What happens to bookmarked links when I reorganize my documentation?">
|
|
Bookmarked and shared links become 404 errors without redirects. Set up redirects in your `docs.json` whenever you move or rename a page. Redirects are cheap to add and prevent a poor user experience for anyone who linked to your documentation from an external source—blog posts, Stack Overflow answers, internal wikis.
|
|
</Accordion>
|
|
|
|
<Accordion title="How many internal links should a page have?">
|
|
Link whenever a related concept is genuinely useful to the user in that moment—not to meet a quota. Too few links leave users without context or next steps. Too many links turn the page into a navigation exercise that pulls users away from what they're trying to do. As a rough heuristic, link the first mention of a concept or tool, and don't repeat the same link multiple times on a single page.
|
|
</Accordion>
|
|
</AccordionGroup>
|
|
|
|
## Related resources
|
|
|
|
- [Format text](/create/text): Markdown formatting options including heading IDs and anchor behavior.
|
|
- [Navigation](/organize/navigation): Configure your documentation structure.
|
|
- [Redirects](/create/redirects): Set up redirects for moved content.
|