Good documentation should be easy to find, clear when shared, and consistent even when individual pages do not have custom metadata. In Doxbrix, this baseline is...
Good documentation should be easy to find, clear when shared, and consistent even when individual pages do not have custom metadata. In Doxbrix, this baseline is...
Good documentation should be easy to find, clear when shared, and consistent even when individual pages do not have custom metadata. In Doxbrix, this baseline is defined in SEO & Social.
This guide explains how to configure those defaults professionally so the site is ready for search engines, link previews, and multi-language publishing.
Who this is for
- teams launching public documentation
- teams cleaning up inconsistent titles and descriptions
- teams publishing help centers or docs sites that will be linked from product, marketing, or support channels
What you will configure
In Project settings → SEO & Social, review:
- Meta title template
- Fallback meta description
- OG image
- Locale alternates
- Search engine hints
These settings act as project-level defaults. They are especially important for pages that do not yet have page-specific metadata.
Why project defaults matter
Without strong defaults, published pages often end up with:
- vague browser titles
- inconsistent search result snippets
- poor social preview cards
- missing locale signals on translated content
- unclear indexing behavior
Project-level SEO settings solve that baseline problem. They give every page a credible starting point, even before teams optimize important pages individually.
Step 1 — Write a practical Meta title template
Start with Meta title template.
This template should make page titles:
- recognizable
- readable
- brand-consistent
- useful in search results and browser tabs
The goal is not to maximize branding. The goal is to make the page understandable when seen out of context.
Good title patterns usually combine:
- the page title
- the product or docs brand
Examples of good outcomes:
- API authentication | Doxbrix Docs
- Import content | Doxbrix Documentation
Avoid:
- overly long suffixes
- internal team names
- title formats that make many pages look identical
Step 2 — Set a strong Fallback meta description
Next, write Fallback meta description.
This description should explain the purpose of the documentation site in clear, reader-facing language. It is not a marketing slogan and it should not read like internal product positioning.
A strong fallback description is:
- specific
- useful to a first-time visitor
- accurate for most pages in the project
- short enough to remain readable in search results
Good themes include:
- what readers can learn here
- what product area the docs cover
- who the documentation is for
Avoid:
- generic phrases like "best-in-class platform"
- stuffing keywords unnaturally
- promises that only apply to one small section of the site
Step 3 — Add a default OG image
Set OG image so shared links produce a polished preview by default.
This image is used when:
- a page is shared in chat or collaboration tools
- a page is posted internally or externally
- a page does not define a more specific preview image
Choose an image that is:
- clearly branded
- readable at small preview sizes
- relevant to the docs property
- stable enough to represent the project broadly
Step 4 — Turn on Locale alternates for multi-language docs
If your project supports more than one language, review Locale alternates.
Turn Locale alternates on when:
- the same content exists in multiple languages
- you want crawlers and readers to understand those relationships
- your language strategy is already reflected in the project structure
Leave it off if the project is currently single-language or if translated content is not yet organized consistently enough to publish confidently.
Step 5 — Add Search engine hints carefully
Use Search engine hints for search or indexing targets that need to be declared at the project level.
Enter one target per line, exactly as intended by your publishing or indexing strategy.
This field is useful when:
- you have a defined internal search indexing workflow
- you need to guide downstream discovery systems
- your team has specific crawler or search target requirements
Do not add values here casually. If your team does not have a clear reason for a hint, leaving the list minimal is usually better than inventing signals that nobody maintains.
Step 6 — Align SEO defaults with Publishing Controls
SEO settings should be reviewed together with Publishing Controls, especially:
- Canonical URL
- Robots rule
- Sitemap generation
- Indexing policy
These settings work as a set.
For example:
- a clean Meta title template is less useful if the wrong Canonical URL is set
- a strong OG image matters most when the published domain and indexing posture are already correct
- Locale alternates are most effective when the site’s multi-language structure is actually live
Step 7 — Test a few representative pages
After saving the settings, validate the outcome on real pages.
Test:
- a top-level landing page
- a standard article
- a translated page, if applicable
- a shared link preview in chat or collaboration tooling
Look for:
- readable page titles
- accurate fallback descriptions
- correct preview image behavior
- consistent branding across shared links
Recommended starting profile
For most public docs sites:
- Meta title template: page title plus docs brand
- Fallback meta description: a concise site-level explanation
- OG image: a branded default image
- Locale alternates: on only when multiple published languages exist
- Search engine hints: only values your team actively uses
Common mistakes
- writing titles that are too long
- using a fallback description that sounds like a homepage headline
- forgetting the default OG image
- enabling Locale alternates before translations are ready
- filling Search engine hints with placeholder values