English (United States) Čeština Deutsch Español (España) Français (France) Italiano 日本語

Debug and QA the Frontend

Who does this article apply to?

  • Enterprise, Partner, and Small Business accounts.
  • Accounts in all regions.

Debug the Frontend

If you see an issue with the quality of your search results (what results are returned and the order they are returned in), you'll want to debug the backend. When you notice display issues on a Search page, you'll want to debug the frontend.

You can debug the frontend using Live Preview, a deploy preview link, or a staging link to check for visual issues or errors. It's possible that your recent build or preview has produced some unexpected results on the frontend, like the below:

Result cards missing information error on universal results

Here the FAQ vertical is not using the accordion card type (which isn't typical of FAQ cards) and the vertical is also missing a "FAQs" section title. This is a signal to check the frontend files, where you configure your verticals and data mappings for the experience.

There are two ways to debug these types of issues:

  1. Inspect the frontend — review error messages for the page or component using the browser inspect tool
  2. Review the Code Editor and Console — look for Jambo error messages and syntax error indicators

Common Frontend Issues

Some common issues to look out for when reviewing your frontend:

  • Vertical tabs are not appearing
  • Vertical section titles are not appearing
  • Vertical page is missing a meta title or meta description
  • "View all" links lead to a dead page
  • Entering a search query produced a blank page
  • Data mappings are not appearing on the card (could be a frontend card mapping issue or a backend API issue)
  • You see a bunch of horizontal gray lines instead of result cards (the cards can't be shown so you're seeing blank cards)

Inspecting the Frontend

Use the browser's "inspect" functionality to identify frontend issues. Right-click on a page, select Inspect, and navigate to the Console tab. If there are issues with the frontend JavaScript, they'll show up in red:

Browser inspect functionality showing an error for MapProviderKey

In this example, the blank page produced a console error reading "MapProviderKey is not defined." From this you can infer there is an issue with the Maps API Key and troubleshoot from there.

Section on Card Is Blank

FAQs result card with a section appearing blank

A section on a card appearing blank usually indicates a poorly mapped section on your card. Common reasons:

  • Incorrectly mapping to a field — e.g., forgetting to include profile. before a field, or omitting the c_ for a custom field
  • Incorrectly referencing a formatter name
  • Needing a null-check on a field that might have an empty value
  • Incorrectly referencing a card

In the example above, the card name likely isn't being referenced properly in the cardType object of the pages config file. This is revealed by the following console error:

Browser Inspect console with a card type error message for accordion card

Debugging with the Code Editor and Console

As you write code, the Code Editor shows issues with red underlining and a red indicator to the right of the affected code line. This helps identify syntax-related issues such as a missing , or unclosed parentheses ().

Code error red underline and indicator in the Code Editor

Error message on hover for code with red underline

Hover over the red underlining to see error messages noting syntax errors such as unexpected characters or incorrect field references. In the example above, VerticalResults is underlined because it's expecting a comma before it, and the comma on line 16 is underlined because it is extraneous.

Page Components Aren't Visible

Page components not visible on results page

If your experience is coming up blank or components aren't rendering, it is likely due to a syntax error. Open the console to see where an issue or typo occurred — especially useful if you've made many changes in a single session.

In this case, the console error notes an "Unexpected token ," in the faqs.json config file. Once removed, the page renders properly.

Console error messaging noting an unexpected token

Universal results page with "restaurant near me" query

For common console errors and what they mean, see the Common Console Errors reference doc.

Types of QA

Getting Yext Search integrated on the site's main domain is very important so you can make improvements based on real user data. However, it's also imperative to QA your search experience thoroughly before integrating with the site's main domain. You want to ensure that all top priority queries are returning optimal results before going live. Post-launch enhancements should consist of smaller incremental improvements such as adding a synonym in the backend or adding more content to the platform.

There are four types of QA to complete prior to launch:

  1. Browser & Device Testing
  2. Search Quality Testing
  3. UI Testing
  4. Analytics Testing

Browser & Device Testing

Browser testing requires you to test your Search experience on different browser types and devices to ensure the experience performs consistently. Yext recommends using an emulator like Browserstack to easily test across browsers and devices.

Test all Search experiences on the following:

  • Google Chrome (latest two versions)
  • Firefox (latest two versions)
  • Safari
  • Microsoft Edge
  • Android (Chrome and Firefox)
  • iPhone (Safari, Chrome, and Firefox)
  • Tablet (Safari, Chrome, and Firefox)

Test the latest two versions of Chrome and Firefox, as they are the most commonly used browsers. For all others, testing the latest version is sufficient.

Browser Testing Expectations

Review all aspects of the Search experience you have turned on in the frontend, clicking all links and features across every vertical. Ensure the following are functioning properly for each browser or device:

  • A map appears on both universal and vertical search (where applicable)
  • All hyperlinked text and CTAs are working correctly
  • Target link behavior is correct
  • Moving between vertical tabs and "View All" (universal search) navigation works
  • FAQs expand and collapse correctly

Feature Testing Expectations

Test all components that apply to your experience:

  • Map on both universal and vertical search
  • Direct Answers
  • Vertical Tab and "View All" Navigation
  • Facets and Filter Components
  • Configured No Results Behavior
  • Spellcheck Component
  • Location Bias Component
  • Pagination Component
  • Query Rules
  • Configurable Sorting
  • Custom Backends
  • iFrame (/iframe_test) — only applies if using the JS Snippet integration path

Search Quality Testing

When testing search quality, you'll confirm that the most relevant information in the platform is being correctly returned for a given query.

Run through 20–40 queries and ensure the relevant results are being returned. Identify or create a list of top priority queries — for example, if searching on a restaurant's website: "Restaurants near me," "How many calories are in a breakfast burrito?," "What allergens are in a fish taco?," etc.

Types of Search Quality Issues

When assessing results for any given query, there are three main buckets that categorize the issue:

  • Knowledge Graph Issue: There is no content in the platform that addresses the query.
  • Configuration Issue: Backend configuration options (e.g., searchable fields, synonyms) need to be adjusted to return the relevant entities.
  • Algorithm Issue: Although the platform has relevant data and the configuration is as optimized as possible, the Search algorithm is not correctly matching or ranking the content.

User Interface (UI) Testing

Once you're comfortable with the search results, confirm that they're visually appealing. Ensure the experience looks consistent throughout and that there are no visual defects. The look and feel should match brand guidelines and expectations such as color scheme and fonts.

Types of UI Issues

If something looks wrong with the frontend, it's likely due to one of these:

  • Visual: An issue with the branding or layout of visual components
  • Data: Data mapping or text labels on the experience are incorrect
  • Technical: Functional issues with the user interface

Analytics Testing

Part of what makes Search such a valuable product is the real-time search analytics that track what a user searches and how they engage with your content. Ensure these events are firing properly before going live.

Examples of analytics events tracked:

  • AUTO_COMPLETE_SELECTION
  • THUMBS_UP
  • THUMBS_DOWN
  • ROW_EXPAND

For a complete list of analytics events, see the Search Analytics Event Types reference doc.

How to QA Analytics

  1. Right-click anywhere on your search experience and select Inspect to open the browser pane.

  2. Select the Network tab from the header, and click Preserve Log so that events stay active.

    Network tab in the inspect console on the frontend

  3. Run a query in the search bar of your Search experience.

  4. Click one of the CTAs in the experience (it's easiest to open in a new tab). You will see a numbered event (your account ID) get logged in the Network console — this means an analytics event has properly fired.

    Network tab in inspect with ID listed in the log

  5. Click into the event in the Network tab. Scroll to the bottom of the window and find Request Payload. Click the accordion next to data to expand the content. Confirm that the correct attributes have been passed — entity ID, event type, vertical configuration ID, etc.

    Network tab in inspect — view Request Payload data

If all of that is correct, the analytics event has fired successfully.