Should you keep or remove old FAQ pages during a redesign?

You should usually keep old FAQ pages only if they still answer a real user question, attract qualified search demand, or support conversion. A redesign is not a good reason to delete them. It is the right moment to audit them, merge weak pages, improve strong ones, and remove only the URLs that are obsolete, duplicated, legally risky, or unsupported by current services.

In practice, the best decision is rarely “keep everything” or “delete everything.” It is selective consolidation. If an FAQ page has rankings, backlinks, internal search usage, assisted conversions, or recurring customer-support value, preserve it and improve it. If it is thin, outdated, contradictory, or cannibalises better commercial or editorial pages, redirect or fold it into a stronger destination instead. Google still rewards helpful, people-first content and good page experience, while FAQ structured data alone no longer creates broad visibility gains for most sites. ([developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content?utm_source=openai))

The safest redesign method is to treat FAQ content as an information asset, not as a template block. Review every FAQ URL against user intent, organic performance, support usefulness, and business relevance. Then classify each page into four actions: keep, merge, rewrite, or remove. That protects SEO equity, improves SXO, and creates cleaner source material for AI-driven discovery, answer engines, and LLM citation patterns.

Why FAQ pages still matter in a redesign

Old FAQ pages often carry more value than teams expect. They can rank for long-tail questions, capture pre-sales intent, reduce support friction, and strengthen internal linking to service pages. For redesign projects, this matters because deleting question-based URLs without evidence often removes the exact content layer that helps users compare options, clarify objections, and convert later in the journey. Google’s guidance continues to prioritise helpful, reliable, people-first content rather than content built only for search features. ([developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content?utm_source=openai))

They also matter beyond classic SEO. Good FAQ content can support SXO by reducing hesitation, AEO by giving concise answer formats, and LLM visibility by exposing clear, scannable question-answer pairs that models can more easily interpret. Google’s documentation on AI features says the same foundational search practices still apply: technical accessibility, policy compliance, visible content alignment, and useful information. ([developers.google.com](https://developers.google.com/search/docs/appearance/ai-features?kgs=aa0bcc3d152ed142&utm_source=openai))

When keeping an old FAQ page is the right choice

  • The page answers a recurring customer question that sales or support teams still receive.
  • The URL earns organic traffic or impressions, especially on long-tail queries.
  • The page attracts backlinks or is cited in documentation, emails, or external resources.
  • The content supports conversion by resolving objections on pricing, process, delivery, compliance, timing, or scope.
  • The page fills an intent gap not covered well by category, service, or product pages.
  • The local variant matters, for example questions about service areas, implementation conditions, or regional constraints.

When removal or consolidation is the better option

  • The answers are outdated after product, pricing, policy, or service changes.
  • Several FAQ pages target the same question and compete with each other.
  • The page is thin, with shallow answers that add no unique value.
  • The FAQ exists only for search footprint and has no clear audience.
  • The page conflicts with current commercial pages and sends mixed messages.
  • The content belongs inside a stronger destination, such as a service page, local page, knowledge base article, or case-study hub.

The audit method to use before deciding

  1. Inventory all FAQ URLs. Include live pages, orphan pages, paginated archives, tag-based FAQ sections, and hidden URLs that still receive traffic.
  2. Pull performance data. Review clicks, impressions, ranking queries, assisted conversions, engagement, internal search demand, and support-ticket themes.
  3. Check authority signals. Look for backlinks, internal links, external mentions, and pages that other teams still use.
  4. Score content quality. Is the answer accurate, complete, current, specific, and better than what a service page already says?
  5. Map each page to a primary intent. Informational, commercial investigation, transactional support, post-sale support, or local intent.
  6. Assign one action per URL. Keep, merge, rewrite, redirect, or remove with a justified status decision.

This is the same logic we apply in a structured website redesign process: content decisions should follow evidence, not aesthetics.

How to judge FAQ pages for SEO

For SEO, the main risk is not having FAQ pages. The risk is changing or deleting URLs that already hold relevance without preserving intent and equity. During redesigns, many traffic losses come from broken URL mapping, weaker replacement pages, or merged content that no longer targets the original question clearly.

Keep a page if it owns useful queries and still satisfies them. Merge it if another page can satisfy the same query better and more completely. Remove it only if no valuable search demand, link equity, or business usefulness remains. If you remove or merge, use clean redirects to the most relevant destination, not to the homepage.

Also remember the 2026 context: FAQPage structured data is not a broad visibility lever for most brands. Google limited FAQ rich results years ago mainly to well-known government and health sites, so the redesign decision should focus on content value, not on the hope of rich-result expansion. Structured data can still help machines understand the page, but it does not justify keeping weak content. ([developers.google.com](https://developers.google.com/search/blog/2023/08/howto-faq-changes?utm_source=openai))

How FAQ pages affect SXO, AEO and LLM visibility

From an SXO perspective, FAQs are useful when they reduce friction at the right moment: before contact, before quote request, before checkout, or before a technical decision. A short answer block on a service page may outperform a separate FAQ page when the intent is tightly linked to conversion. A standalone FAQ page may work better when the question set is broad and discovery-led.

For AEO and LLM visibility, structure matters. Pages that present a clear question, a direct answer, supporting detail, and consistent terminology are easier to extract, summarise, and cite. That does not guarantee visibility in AI features, but it improves machine readability. Google’s AI features guidance still points back to visible-text alignment, technical crawlability, and strong core content fundamentals. ([developers.google.com](https://developers.google.com/search/docs/appearance/ai-features?kgs=aa0bcc3d152ed142&utm_source=openai))

If your redesign includes a dedicated AI-search strategy, connect FAQ decisions with your broader GEO and LLM visibility work rather than treating them as isolated pages.

Structured data: use it carefully, not mechanically

If an FAQ section is truly an FAQ page written by the site, structured data can still be valid as long as it matches the visible content and follows Google’s general structured data rules. But it should be applied only where the page genuinely contains stable, user-facing question-answer content. Google explicitly states that correct markup does not guarantee rich-result display, and policy violations can affect rich-result eligibility. ([developers.google.com](https://developers.google.com/search/docs/appearance/structured-data/sd-policies?utm_source=openai))

In redesigns, common mistakes include:

  • marking up hidden accordion content that is not meaningfully visible,
  • using FAQPage on pages that are really forum or community Q&A content,
  • keeping legacy schema that no longer matches the rewritten copy,
  • duplicating the same FAQ schema across many near-identical pages.

If structured data is part of the project, validate it with the same discipline as templates and redirects. This is where a dedicated structured data implementation is useful.

Performance and template risks during redesign

FAQ content is often placed inside heavy accordion components, tab systems, or JavaScript blocks introduced by new design systems. That can hurt usability and performance if the redesign adds unnecessary script weight or delays rendering. Google recommends good Core Web Vitals, including LCP within 2.5 seconds, INP under 200 milliseconds, and stable layout. ([developers.google.com](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=openai))

So the right question is not only “keep or remove the FAQ page?” but also “how is the FAQ delivered?” A slimmer page with server-rendered text, clean headings, and accessible expand/collapse behaviour is usually better than a visually impressive but slow component library.

What to do with local FAQ pages

Local FAQ pages should be reviewed even more strictly. Keep them when the answers are genuinely location-specific: service coverage, delivery constraints, appointment conditions, legal or practical differences by city or region, or local proof points. Remove or merge them when they are just duplicated master content with a place name swapped in.

For multi-location redesigns, a better model is often to place local FAQs inside robust location pages instead of multiplying weak standalone URLs. That improves relevance and reduces duplicate-content risk while keeping the answers close to the local conversion path.

Concrete agency actions during a redesign

  • Create a URL decision sheet for every FAQ page with status, metrics, target intent, and redirect mapping.
  • Compare old FAQ queries with new IA to ensure no question cluster disappears unintentionally.
  • Rewrite weak answers into concise first-answer paragraphs followed by practical detail.
  • Merge overlapping pages where one stronger destination can satisfy the full question set.
  • Preserve internal links from guides, blog posts, service pages, and support content.
  • Validate schema and visible content alignment before launch.
  • Test templates for speed and accessibility, especially accordion behaviour on mobile.
  • Monitor post-launch with crawl checks, Search Console, analytics, and support feedback in the first weeks.

If redesign decisions also affect core service positioning, align them with broader SEO and SXO optimisation and with the future information architecture of the site.

The checks to make before launch

  1. No valuable FAQ URL is left without a mapped destination.
  2. Redirects point to the closest intent match, not to generic pages.
  3. Kept pages answer the query better than before, not just with new design.
  4. FAQ sections are crawlable and visible in the rendered page.
  5. Structured data matches the final on-page wording.
  6. Core Web Vitals are not degraded by redesigned components. ([developers.google.com](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=openai))

The practical rule to apply

Keep old FAQ pages when they still earn trust, traffic, or conversion assistance. Remove them when they are obsolete, duplicative, or strategically empty. Merge them when the same intent can be satisfied better on a stronger page. In most redesigns, the winning move is not deletion; it is rationalisation.

If you are planning a redesign, the next step is simple: build a FAQ URL audit, score each page across search value and user value, and decide keep, merge, rewrite, or remove before any design templates are finalised. If you want that audit tied directly to the new site structure, start with a redesign review or contact our team.