XenForo Engineering

A front page over a XenForo community

A forum's homepage is a list of forums, which is the right page for members and a poor one for everyone else. A portal is the answer to that, and it raises a question the forum did not have: which of the two is the site.

The problem

A forum is organised for members and read by everybody else

The forum index lists categories in the order the community thinks in, which is exactly right for someone who is already a member and largely opaque to a visitor who arrived from a search result. A portal gives that visitor an entrance: what the community is, what is being discussed, and a way in. The work is deciding what belongs there, because a portal that duplicates the forum has added a surface without adding a reason to visit it.

  • The site's front page is a list of forums, which explains nothing to a new visitor
  • Search traffic lands on threads and never reaches the community's identity
  • The forum has content worth surfacing and no way to surface it
  • A portal exists and has become a second place to maintain content
  • The portal and the forum both try to be the homepage
  • Featured or promoted threads have to be managed by hand
  • The front page has not changed in months because updating it is work
  • Nobody can say what the site's main URL should show
Who this is for

The people who usually bring us this problem

A community whose front page does not explain it

Visitors arrive from search, land on threads, and never see what the community is.

Someone with a portal that has become a burden

It needs maintaining separately and it duplicates the forum.

A community that publishes as well as discusses

There is editorial content alongside the discussion and no place for it to live.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

A portal that duplicates the forum has added nothing

If the front page shows the same threads the forum index shows, in a different order, it is a second view of one thing and it will not be maintained. A portal earns its place by showing something the forum cannot: curated selections, editorial pieces, structured entry points into the community's knowledge.

Two surfaces means two things to keep correct

URLs, canonicals, sitemaps, structured data and internal linking have to be right for both, and the relationship between them has to be deliberate. Which page a query should land on is a decision, and leaving it to whichever the search engine encountered first is how a community ends up with its forum and its portal competing.

Manual curation stops happening

A featured list maintained by hand is maintained for a few months and then is not. Whatever the portal shows has to come from the community's own activity — what is being discussed, what is new, what is most engaged with — so that it stays current without anyone tending it.

A portal changes what the site's main URL is

The forum index is at one address and the portal is at another, and one of them is the site. That decision affects navigation, canonical URLs, the sitemap and where the homepage is — and it is better made once than discovered from a search result.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

What the portal is for, decided first

The visitor it serves and the question it answers. A portal for people who arrived from search is a different page from one for returning members, and establishing which one this is determines everything that follows.

Content selection driven by activity

What the portal shows, derived from the community's own signals — recent activity, engagement, staff selection, tag or prefix — so it stays current without manual maintenance. Where curation is genuinely needed, it is a small editorial layer over an automatic base.

The relationship between portal and forum

Which URL is the site, what each surface is for, and how a visitor moves between them. Decided explicitly, because both pages existing without a relationship is how they end up competing.

Editorial content alongside discussion

Where the community publishes as well as discusses, a place for that content with its own structure — rather than a forum thread pretending to be an article, which is what happens when there is nowhere else for it.

Structured entry points

Ways into the community's knowledge for someone who does not know it: popular or answered threads, topic collections, guides built from existing discussion. This is the value a forum index cannot provide.

Navigation and discovery

How the portal, the forum and the individual threads relate for a reader and for a crawler, including the internal linking that decides which pages are reachable from the front page.

Search configuration across two surfaces

Canonicals, sitemaps, structured data and the decision about which surface should rank for what. A community with a portal has a wider URL estate than one without, and it needs an indexation model rather than a default.

Performance at the front door

The portal is the most-requested page on the site and it aggregates content from across it, which makes it the page most likely to be slow. Its query and caching behaviour is designed rather than inherited.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

  1. Establish who the front page is for

    A visitor from search, a returning member, or both — and if both, which takes precedence in the layout. This is a positioning decision rather than a design one, and it is made before any structure is proposed.

  2. Derive the content from activity rather than from a list

    Whatever the portal shows should be computed from what the community is doing, so it is current on the day it is first needed. A curated list is added as a layer over that, not as the mechanism.

  3. Decide the site's main URL explicitly

    Portal or forum index, chosen and documented, with the navigation, canonical and sitemap consequences carried through. Leaving it undecided is how two pages end up competing for the same query.

  4. Do not build a second content store

    Editorial content gets a real home with its own structure; anything that is discussion stays discussion. The failure mode is a portal that becomes a parallel CMS nobody updates, and it is avoided by giving each type of content one place to live.

  5. Design the entrance for someone who does not know the community

    The portal is read by people who have never been to the forum. What the community is, what it is about, and how to find the thing they came for — in that order, and in the first screen.

  6. Configure both surfaces for search together

    Canonicals, sitemaps and structured data decided across the portal and the forum as one estate. Two surfaces configured separately is how a community develops duplication it did not intend.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Definition

  • Who the front page serves, and what question it answers
  • What the portal shows, and which community signal supplies it
  • Whether the portal or the forum index is the site's main URL
  • How the two surfaces relate for a reader and for a crawler
  • Where editorial content lives, if there is any

Build

  • The portal, driven by the community's own activity
  • Structured entry points into the community's knowledge
  • Navigation and internal linking across both surfaces
  • Canonicals, sitemaps and structured data configured as one estate
  • Query and caching work for the site's most-requested page

Handover

  • What is automatic and what, if anything, is curated
  • How to change what the front page shows
  • Which URL is canonical for the site, and what that means for links
  • What the portal does not do, and what belongs on the forum instead
  • How the two surfaces are kept from competing
Under the hood

Architecture and technology

What a portal can show that a forum index cannot

  • What the community is, in one screen, for someone who has never seen it
  • Discussion selected by engagement rather than by category order
  • Structured entry points: answered questions, popular topics, guides
  • Editorial content, where the community publishes as well as discusses
  • Recent activity as evidence that the community is alive

What a portal gets wrong

  • Showing the same threads the forum index shows, reordered
  • A curated list that stops being curated within a few months
  • Becoming a second CMS with content maintained separately
  • Competing with the forum index for the same queries
  • Being the slowest page on the site because it aggregates everything
  • Explaining the community to members who already know it
Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

The community is being moved to XenForo

Source conversion, compatibility and reconciliation.

Forum migration to XenForo

The forum's search performance needs work

Thread and pagination indexation, duplication and crawl health.

XenForo forum SEO

The community needs custom functionality

Add-ons and integrations beyond what the platform provides.

XenForo add-on development

The design needs rebuilding

Upgrade-safe theming for the community and its front page.

XenForo theme development
Questions

Frequently asked

Should the portal or the forum index be our homepage?

It depends on who arrives and what they need first. If a significant share of your visitors come from search and have never heard of the community, a front page that explains it is worth more than a category list — and the forum index stays one click away, which is where members go anyway. If your audience is almost entirely returning members, the forum index is already the right page and a portal adds a step. It is a positioning decision rather than a technical one, and the important part is deciding it explicitly, because both pages existing without a stated relationship is how they end up competing for the same queries.

Do you have a portal you built?

We have built one historically, and it is not published as a case study — the scope, the intellectual property position and the visuals would each need approval that is not recorded. So the page claims no reference rather than pointing at a forum and implying a case. What it describes is the design problem, which is what a reader actually has to decide: what the portal shows, where it comes from, and how it relates to the forum.

How do we stop the portal going stale?

By deriving what it shows from the community's own activity rather than from a list somebody maintains. Recent discussion, engagement, staff selection and tags are all signals the platform already has, and a portal built on them is current on the day it is needed without anyone tending it. A manually curated front page is maintained for a few months and then is not, and that pattern is predictable enough to design around rather than hope against.

Will a portal hurt our forum's search visibility?

It can, if the two surfaces are configured independently. A community with a portal has a larger URL estate than one without, and the questions are the same ones a forum always has — which pages should be findable, which URL is canonical, and how the pages link to each other. Configured as one estate, a portal improves discovery by giving the community a page that can rank for what it is rather than only for individual threads. Configured separately, the two compete for the same queries and neither accumulates enough evidence.

Where should editorial content live?

In its own place with its own structure, if the community publishes as well as discusses. A forum thread pretending to be an article is what happens when there is nowhere else for it — it has a discussion's URL, a discussion's metadata and a discussion's structure, none of which suit a piece of writing. Giving editorial content a real home also stops the portal becoming a parallel CMS, which is the failure mode of a portal that tries to hold both.

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.