How SEO works on your portal

Your portal isn’t just a support tool, it’s built to be found by search engines. Every public question and reply is a real, indexable page, so the support you already provide keeps paying off in search traffic.

A help center where the answers came from customers

It helps to think of your portal as a help center with a community behind it. Every page in it started as a question a real customer asked, in the words they used, and each answered thread becomes its own page at its own URL. So the archive tends to match what people type into a search box: you’re not guessing at topics, you’re publishing answers you already gave.

Every reply is a page

Public questions and their replies are server-rendered, not hidden behind client-side JavaScript, so search engines can crawl and index them like any other web page. Question lists, category pages, and pagination all use real links, so crawlers can follow your entire portal without extra work on your end. Reading takes no account either: a crawler, an AI engine, and a customer who has never signed in all get the same full page.

Private questions and questions in private categories are excluded from all of this: they never appear in search results, listings, or the sitemap. See Organize with categories & tags.

Category and tag pages have their own URLs

Filtering the question list by category or tag lands on its own crawlable URL (/c/{category} for a category, /t/{tag} for a tag) rather than a query parameter, so search engines can index each one directly instead of treating it as a variant of the home page. Only one filter applies at a time: picking a category or a tag takes you to that page, and picking the other one switches to it instead of combining the two.

Pagination uses clean, crawlable URLs

When a question list runs past the first page, the later pages get their own clean URLs rather than a query parameter: the first page is the plain list address, and page two onward reads /page/2, /page/3, and so on. It’s the same shape on the home list, category pages, and tag pages (/c/{category}/page/2, /t/{tag}/page/2). The page links are real links, so a crawler can walk the whole archive, and each page is its own canonical URL (with rel=prev and rel=next hints), so search engines treat page two as a page in its own right, not a duplicate of page one. Searching or changing the sort order stays a regular query option and resets you to the first page, so those never fragment the crawlable set.

Page titles carry your forum’s name

Every question list page, whether that’s the portal home, a category, a tag, or any of their later pages, ends its browser-tab title with your forum’s name (for example “Questions & answers · Acme Support”), so a search result or a browser tab identifies which forum it’s from at a glance instead of every forum showing the identical generic title. A page past the first also names its place in the series (for example “Questions & answers · Page 2 · Acme Support”), so search engines and visitors can tell page two of your question list apart from page one instead of seeing two pages that look identical.

URLs that don’t break when titles change

Every question has a URL shaped like:

/q/{number}/{title-slug}

for example /q/42/how-do-i-export-my-data.

The number is the real, permanent identifier: the slug is just a readable tail for humans. If someone visits a URL with an outdated or missing slug (even just the bare /q/42), they’re automatically redirected (a permanent, search-engine-friendly 301) to the current, correct URL. Nothing you’ve linked to, in an email, a changelog, a support ticket, ever goes stale, even if a question’s title (and so its slug) changes down the road.

This matters in practice because your team can edit question titles after posting (end-users can’t edit their own posts; see How your customers sign in, ask & vote). Every title edit regenerates the slug automatically: the URL updates to match the new title, and the old URL keeps working via the 301 instead of turning into a dead link or a duplicate-content problem for search engines.

This is also why question numbers are a good shorthand in conversation.

Sitemap

Every forum gets its own sitemap.xml, generated automatically and kept in sync as questions are asked, answered, edited, or made private. sitemap.xml is an index: it lists a small set of child sitemaps rather than every URL directly. There’s nothing to configure: submit your portal’s sitemap URL to Google Search Console once and it stays current on its own.

The child sitemaps are:

sitemap-pages.xml: the portal home page, plus its numbered pages (/page/2, /page/3, and so on) when the question list runs past the first page.
sitemap-categories.xml: your public categories.
sitemap-tags.xml: your tags, limited to tags that appear on at least one public question.
sitemap-questions-1.xml, sitemap-questions-2.xml, and so on: your public questions, split into chunks of 5,000 so a single file never grows unbounded. Each question carries an accurate lastmod date that reflects both edits and new reply activity, so search engines know a thread changed (and is worth recrawling) even when only a reply was added.

Search engines read the raw XML, but if you open sitemap.xml, or any of its child sitemaps, in a browser, you’ll see a readable, branded page instead: your portal’s name, logo, and accent color, with every listed sitemap or URL and its last-updated date in a simple table. Nothing to configure here either, it just reflects your portal’s branding.

You can browse it like a normal page: a child sitemap has an “All sitemaps” link back up to the index, and your portal’s name at the top of either view takes you back to the portal itself.

robots.txt

Every portal also serves its own robots.txt, which points crawlers at the sitemap index. It deliberately allows crawling everywhere: account and utility pages (asking, signing in, your profile, moderation) are kept out of search results with a noindex tag on the pages themselves, which is more reliable than blocking crawlers from ever seeing them. As with the sitemap, there is nothing to configure.

Structured data for Q&A rich results

Every question page with at least one reply includes QAPage structured data (JSON-LD) describing the question, its replies, the solution (if any), vote counts, authors, and dates. This is the format Google looks for to show Q&A rich results directly in search: your reply can appear expanded in the search results page itself, above where a plain link would rank. A question with no replies yet doesn’t carry this markup: Google requires at least one answer for a Q&A rich result to be eligible, so an unanswered question simply omits it rather than shipping structured data that would never qualify.

Every question list page (the portal home, categories, and tags, at every page in their pagination) carries Organization and WebSite structured data naming your forum and pointing at its search, so search engines understand what your portal is and that it’s searchable. Category and tag pages additionally carry BreadcrumbList markup: your forum name, then the active category or tag, which helps search engines understand how that page fits into your portal’s structure. The portal home doesn’t need a breadcrumb since it’s already the top of the structure.

A markdown copy for AI engines and agents

Every public question is also served as a raw markdown document, at the question’s number behind an /md/q/ prefix, and every question page points at it from its <head>. AI engines, agents, and any other machine reader get the question, every reply, and the metadata as plain text, with no HTML to parse and nothing to scrape. There’s nothing to turn on here either. See Markdown view of a question.

Paste a link to your portal into Slack, X, LinkedIn, iMessage, Discord, or anywhere else that shows a link preview, and it renders a branded image instead of a bare URL. This is automatic: every public page generates its own 1200x630 preview image the moment a link to it is shared, there’s nothing to design, upload, or turn on.

There are two card designs, matching what the link points to:

A question card, on every question page: the question’s title (up to three lines), your forum’s name, its reply count and vote score, and a “Solved” badge once an answer is accepted.
A forum card, everywhere else: your portal’s home page and its later pages, category pages, tag pages, and member profile pages. It leads with your logo (if you’ve set one) and forum name, a short tagline, and pills showing your public question count and how many have an accepted answer (each pill only shows once that count is above zero).

Both match your portal’s own look: the accent color and the Light, Dim, or Dark theme you’ve set on the Display tab (see Brand your portal). If your portal’s “Powered by” badge is showing, the same wordmark also appears in the corner of the card, echoing the floating badge in the corner of your portal.

Previewing a card: open the image URL directly in a browser tab, /og.png for your forum card or /og/q/{number}.png for a question (for example /og/q/42.png). That shows you exactly what will render, no need to actually post the link anywhere first.

Refreshing a card: these images are cached briefly for speed, so an edited question title can take up to a day to show up in a freshly generated card. On top of that, most social networks cache the card itself once they’ve seen a link, sometimes for much longer. If you’ve edited a question and its share preview still looks stale, use that network’s own link-preview refresher (for example X’s Card Validator or LinkedIn’s Post Inspector) to make it re-fetch.

Private content stays private: a question that’s private, in a private category, or has been moderated away returns a plain 404 for its image, the same as the page itself. Nothing about a hidden question’s content, title included, ever leaks through a preview card.

A couple of honest limits, worth knowing:

The card’s text uses your portal’s brand font, which covers English and most European languages (including accented characters). It does not currently cover Cyrillic, Greek, Chinese/Japanese/Korean, Arabic, or emoji. A question title that’s mostly in one of those falls back to the plain forum card rather than showing broken text.
You can’t yet upload your own custom preview image, or design a different one per category. Every card comes from the two designs above.

Canonical URLs

Every page declares a canonical URL so search engines know exactly which version to index, even if the same content is reachable more than one way. If you’re on the Basic plan and later connect a custom domain, your subdomain URLs automatically redirect to your custom domain: search engines follow the redirect and consolidate ranking signals onto the new domain instead of splitting them across two.

Links your community posts don’t leak SEO value

Questions and replies support markdown formatting, including links, but every link a community member posts (including a bare URL that’s automatically made clickable) is marked nofollow and ugc (“user-generated content”). Search engines treat those as a signal not to pass along any ranking credit, so there’s no incentive for anyone to spam your portal with links to their own site. Your team’s replies, and the structured data described above, are what search engines index and rank: links posted by the public never affect that.