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.

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.

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.

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.

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 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.

List and category pages carry their own structured data too (Organization, WebSite, and breadcrumb markup), which helps search engines understand how your portal is organized.

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 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, with your forum’s name front and center, everywhere else: your portal’s home page and its later pages, category pages, tag pages, and member profile pages.

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, exactly like it does in your portal’s footer.

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.