Freshdesk Portal Not Showing Articles / Search Broken: Fixes

Why an article you can see is invisible to customers

The agent view and the customer portal view are governed by different rules. Inside Freshdesk, an agent with knowledge base permissions can see drafts, in-review articles, and articles restricted to logged-in users — none of which a signed-out visitor is entitled to. So "I can see it" tells you almost nothing about what the public sees.

For an article to appear on the portal for a given visitor, every gate above it has to open: the article has to be Published (not Draft or In review), the article's own visibility scope has to include that visitor, the folder it lives in has to be visible to that visitor, the category has to be associated with the portal they're on, and the portal has to allow that person to view solutions at all. Miss one and the article vanishes for them while staying visible to you. The fixes below walk that stack top to bottom.

The causes-to-fixes checklist

Work through these in order. The first four cover the overwhelming majority of "article not showing" cases; the last two cover the "it's there but search won't find it" variant.

Fix 1 and 2: publish state and article visibility

Start inside the article itself. Open the article and look at its Article Properties panel. Two things there decide whether it can ever reach the portal.

Publish state. Freshdesk articles move through Draft → In review → Approved (Enterprise) → Published, and only a Published article is eligible to appear on the portal. Per Freshworks' Manage your knowledge base documentation, you can list every unpublished piece via the All drafts and Published articles quick views to catch anything that got left in draft.

Visibility scope. Even a published article carries its own audience setting. Freshdesk's article visibility options let you scope an article to All users, Logged in users, Agents only, or to specific companies, contact segments, or company segments. If it's set to Logged in users or Agents, a signed-out visitor will never see it. For a fully public help center, this needs to be All users.

The screenshot above shows the healthy state you're aiming for: status Published and the folder set to Visible to: All Users. Note that the "Visible in: Acme Inc" line is the category-to-portal association, and it matters just as much — an article can be published and public and still miss the portal you expect if its category is pointed at a different one.

Fix 3: folder visibility

Article visibility is only half the story, because folder visibility overrides it. A folder set to Logged in users will hide even an "All users" article inside it from signed-out visitors. Freshworks notes that new folders are visible to everyone by default, but any change you (or a predecessor) made sticks.

1. Go to Solutions, open the relevant category, and select the folder.
2. Open the Visible to dropdown for that folder.
3. Choose All Users for a public help center, or the specific companies/segments you intend.
4. Save, and re-check the article on the portal.

If you run a closed help desk, this is also where the classic "recent articles" widget breaks: the recent-articles placeholder only surfaces public articles, so folders locked to logged-in users won't feed it.

Fix 4 and 5: portal association and the master access gate

Two portal-level settings sit above everything you've done so far.

First, category-to-portal association. Categories are mapped to a specific product portal; an article whose category isn't associated with the portal a visitor is browsing simply won't show there, and unassociated categories are quarantined in their own "Unassociated categories" view. Confirm the article's category is tied to the right portal.

Second, the master gate. Per Freshworks' guide on letting customers view articles without signing in, go to Admin → Channels → Portals → Settings and set Who can view solutions to everybody. If this is restricted to logged-in users, no amount of "All users" visibility on the article or folder will expose it to an anonymous visitor — the portal turns them away before article rules even apply. The same doc is explicit that the containing folder must also be visible to all users for this to work.

Fix 6: search indexing and why portal search feels "broken"

Once an article is published and visible, portal search is the last layer — and it behaves differently from a simple "is it live" check. Freshdesk's portal search runs on Elasticsearch, and per community guidance a newly created or edited article takes a few minutes to get indexed before it becomes findable. So if you just hit Publish, give it a moment before concluding search is broken.

Two more realities worth knowing. Freshdesk indexes an article's content up to a 64 KB ceiling, so extremely long articles may not have every word searchable. And the match is fairly literal — long-standing user reports note it doesn't always treat word variants (like "register" and "registering") as equivalent, so a customer's phrasing has to be reasonably close to your article's wording to get a hit. If search still returns nothing after indexing, re-confirm the publish state and visibility first: an unpublished or logged-in-only article is excluded from anonymous portal search results regardless of how good the query is.

Separately, if your complaint is that the portal isn't showing up in Google — as opposed to the on-portal search box — that's an SEO indexing question, not a Freshdesk visibility one. The usual fixes are checking your canonical/alternate tags and submitting the affected URLs through Google Search Console's URL Inspection tool to request a re-crawl.

The honest limits — and where an AI layer helps

Freshdesk's knowledge base is genuinely capable, and its visibility model is doing exactly what it's designed to do: give you granular, deterministic control over who sees what. The publish states, per-article and per-folder scopes, portal gating, and segment targeting are all legitimately useful once you understand the stack — this isn't a bug, it's layered access control.

Where it runs out of road is on the customer's side of the search box. Portal search is keyword-literal: it can't reason about intent, it doesn't reliably normalise word variants, and it returns a list of links a frustrated customer still has to read through. A published, perfectly-visible article can go unfound simply because the visitor typed the problem in words that don't match your title. And none of this helps the customer who never visits the portal at all and just emails a ticket.

This is the seam where an AI agent layer fits, and it's worth understanding the broader category of AI agents for customer service before reaching for one. Macha is one such layer that runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk, your portal, or your knowledge base. You connect Macha to Freshdesk with your subdomain and API key, and it reads the same published solution articles your portal serves, then uses them to answer customers by intent rather than exact keyword — drafting or posting a grounded reply directly in the ticket, and pulling live order or account status through a custom tool when the article alone isn't enough. It slots naturally alongside the automations you already run in Freshdesk, and if you're mapping out where this could go, our guide on how to automate Freshdesk with AI walks the options.

Two honest caveats: Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. And credits are consumed per AI action, not per resolution, so the pricing scales with the work the agents do rather than with tickets closed. The clean division of labour: keep Freshdesk's knowledge base and portal as the system of record for what's documented and who can see it, and layer an agent on top for the part portal search can't do — understanding what the customer actually asked and answering it, even when their words don't match your article's.

FAQ

Why can I see a Freshdesk article but customers can't? Because the agent view and the public portal apply different rules. A signed-out visitor only sees articles that are Published, scoped to All users, sitting in a folder Visible to All Users, in a category associated with the portal, on a portal whose Who can view solutions setting allows anonymous access. If any of those is stricter, the article stays visible to you and hidden from them.

Where do I change article and folder visibility in Freshdesk? Article visibility lives in the article's Article Properties (Visible to: All users, Logged in users, Agents, or specific companies/segments). Folder visibility is set under Solutions → Category → Folder → Visible to. Both must include your intended audience — folder visibility can override article visibility.

How do I let customers read articles without logging in? Go to Admin → Channels → Portals → Settings and set Who can view solutions to everybody, and make sure the containing folder is Visible to All Users. Both are required for unauthenticated access.

Why isn't my new article showing up in portal search? Freshdesk's search runs on Elasticsearch and takes a few minutes to index new or edited content, so wait briefly after publishing. Search is also fairly literal and indexes article content up to 64 KB, so word variants and very long articles may not match cleanly. Confirm the article is published and visible first — unpublished or restricted articles are excluded from anonymous search.

Can I add AI to my Freshdesk knowledge base without replacing it? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and reads your existing published articles to answer customers by intent — it runs on top of your portal and knowledge base rather than replacing them, and it works alongside your current visibility rules and automations.

Ready to help customers get answers even when portal search can't find the article? Start a free trial of Macha and connect it to your Freshdesk in minutes.