Reviewloger — building a unified campaign-listing search service end to end, and its AEO project

Three lines

• Navirang built Reviewloger, a unified search service for brand-ambassador campaign listings, end to end — product design, web development, automated listing collection (62 adapters, 61 currently active), data consolidation, search structure and SEO/AEO structure.
• As of 12 August 2026, 6,147 open listings sit in one common schema, explorable by region, category, platform and closing date.
• An AI search discoverability audit run the same day reproduced a case where the service matched the question’s purpose exactly yet did not enter AI’s first answer candidates. Building a good service and getting AI to discover it are separate problems.

What Reviewloger is

A unified search service that automatically collects campaign listings scattered across several brand-ambassador platforms so they can be explored and compared in one place. Its reason to exist is sparing someone applying to campaigns the need to visit each platform in turn.

Users find listings by region (all 17 Korean provinces down to city and district), by category (nine: food, beauty, living, digital, travel, children, fashion, pets, culture) and by search term, and sort by closing soon, newest, lowest competition or highest reward. Each listing carries a calculated closing countdown and an applicant competition ratio.

Which problems were being solved?

There were two, and the second was found after the service was already built.

The first is a product problem. Campaign listings are scattered across dozens of platforms, each writing region, closing date and reward differently. Finding the listing you want means visiting site after site. What Reviewloger had to solve was collecting and organising scattered listings automatically so they can be found in one place.

The second is an AEO problem. Even after the service was complete and the data had accumulated, when a user who did not know the brand name asked AI, AI did not bring the service back as a candidate. Building a good service and having AI discover that service in a question from a user who does not know its name are separate problems. The second half of this article is the record of diagnosing that gap.

What Navirang built — from design through collection, search and AEO

Every scope statement in this section is drawn only from facts confirmed in the Reviewloger repository code and the production database. What could not be confirmed is not written.

Service design and the web application

The information architecture was designed as “search paths shaped like the question”. People searching by region get a region path, people searching by category get a category path, and people combining the two get a combination path — each as a canonical URL.

Technically it is Astro 5 server-side rendering deployed to the Cloudflare Workers edge, with data in Supabase (PostgreSQL). Every list and filter is rendered as HTML on the server, so crawlers that do not execute JavaScript read the whole body. Filter chips are implemented as canonical path links rather than client scripts — buttons to a person, pages to a crawler.

The automated collection pipeline — nine stages

The core of the crawler system that automatically collects listings from several campaign sites. Sixty-two platform adapters were built, of which 61 are currently active. Every stage from collection to search exists in code.

Stage	What it does
Source	Target platforms are managed in one configuration file. One platform whose robots.txt disallows list collection is excluded from collection
Crawl	robots.txt is checked at request time, requests carry an identifiable bot name, and request intervals are respected. On a blocking signal (403, 429) collection from that site stops immediately
Parse	The differing HTML structures and public JSON responses of each platform are interpreted separately
Normalize	Region, closing date, places available, applicant count, reward, type, channel and category are converted to a common format
Deduplicate	Duplicates are prevented on platform plus source listing ID — a double defence of a database unique constraint and the ingest logic
Store	Loaded in a pending-review state. The original title is not exposed; a title and summary are generated from factual fields such as region, audience and benefit
Update	On re-collection only volatile fields such as closing date and applicant count are refreshed, and values a reviewer corrected are preserved
Expire	Listings past their closing date are closed automatically, and old listings are deleted automatically
Search	The organised data feeds server-rendered exploration along region, category, search term and sort axes

Two further stages sit on top: generating a structured, fact-based summary for pending listings and auto-publishing them, and notifying users through KakaoTalk when a new listing matches their criteria. Collection runs once daily via a GitHub Actions workflow.

Compliance is the default in collection. robots.txt is re-checked on each request, the bot identifies itself by name, request intervals are respected, and a blocking signal makes it back off. No mechanism to circumvent a block was built — one adapter remains stopped because of the target site’s robots.txt policy.

Data consolidation — 62 adapters, one schema

Region is written differently on every platform (“Seoul/Gangnam-gu”, “Gyeonggi Seongnam-si”, “nationwide”), and closing dates appear as “31 days left”, “D-15”, “closes today”. The normalisation layer converts all of it into common fields — region (province and district codes), nine categories, type (visit, delivery, press-corps, packaged), channel (blog, Instagram, YouTube, clips/reels), closing date, announcement date, places available, applicant count, reward.

That consolidation is what makes the data able to answer a request like “visit-type food campaigns in Busan, closing soonest first”. The 62 adapters’ differing structures become one queryable dataset at this point.

SEO and AEO structure

Structure built in from the start so search engines and AI can read what this service means.

• Nine structured data types — Organization, WebSite (with SearchAction), Service, BreadcrumbList, ItemList, FAQPage, Article, AboutPage, Dataset
• A selective sitemap — thin region and combination pages with few listings are excluded from the sitemap. Trying to index a mass of pages that differ only by name invites duplicate judgements
• Collected listing detail pages are noindex — blocking duplicate content signals against the source platform. Indexing belongs to the source; unified exploration belongs to this service
• A measured direct-answer paragraph on every region and category page — values specific to that page (total count, type distribution, competition ratio) calculated at render time. Template sentences with only the region name swapped make pages overlap each other
• Eleven AI crawlers explicitly allowed in robots.txt, an llms.txt, 22 FAQ items (the screen and the FAQPage schema read the same array), RSS, and IndexNow submission

The general principles behind these structures are set out in the AEO practice series.

On 12 August 2026 we asked AI directly

We audited whether the finished service is actually discovered in AI search, using questions from a real user’s point of view. The representative question:

“Where can I see brand-ambassador campaign listings from several platforms in one place?”

In the first general answer, other unified campaign services appeared as candidates first, and Reviewloger was not included in the initial answer.

We then separately verified whether Reviewloger is a service that fits this question. The question’s purpose — exploring several campaign listings in one place — matched the actual service exactly. As of the measurement date, 6,147 open listings from 60 platforms really are explorable in one place.

The service fits the question, yet AI does not bring it back as a candidate — that gap is the core problem of this case study. The general causes of this happening are set out as five items in why ChatGPT does not mention your company.

Discovery → understanding → recommendation, in five stages

When diagnosing this kind of gap, Navirang splits the problem into five stages. It is not an official ranking model published by a search engine or an AI company but the analytical framework Navirang uses to set the order of an audit.

Stage	The question	Reviewloger’s state (audit of 12 Aug 2026)
1 Existence	Does the service exist on the web?	Pass
2 Crawling and indexing	Can search systems reach and collect it?	Access structure in place — server rendering, crawlers allowed, sitemap
3 Understanding	Do search engines and AI know what this service is?	Identity documents and structured data present
4 Discovery	Is it brought back as a candidate for a general question with no brand name?	Absent from the first answer’s candidates — the bottleneck
5 Recommendation	Among candidates, is it included in the actual answer?	Unreachable while stage 4 is unresolved

The important observation in this audit is the gap between stages 3 and 4. Reaching a state where the site can be understood once read is work that finishes inside the site. Making the candidate list for a question with no brand name is a different problem — signals from outside the site have to operate too: mentions on the external web, and the connection between the brand and the category it belongs to. That is the boundary between what can be done inside and what has to be done outside.

Four things this audit established

Below are audit and analysis outcomes. They are not improvement results.

First, the problem was reproduced. We confirmed with real questions that Reviewloger is not included in the first candidates for a general user question. A problem that does not reproduce cannot be confirmed as fixed either.

Second, the cause was narrowed. Because we separately verified that the service fits the question’s purpose, the analysis direction is secured: the problem is not missing functionality but the process of being discovered as a candidate by search and AI.

Third, competing services’ discovery paths were compared. We compared how the services that appeared as candidates first are discovered — search result visibility, how service identity is expressed, external web mentions, landing page composition, brand and category signals. We do not evaluate individual services; we record observations only.

Fourth, the improvement direction was defined. We defined the structure that would make it easier for search engines and AI to read “Reviewloger = a service for exploring several campaign listings in one place”. Applying it, and measuring it, come after this article.

Build outcomes — only what is confirmable in code and data

The figures below were aggregated directly from the production database on 12 August 2026, using the same public query conditions the service uses when rendering its lists.

Item	Value (as of 12 Aug 2026)
Collection adapters	62 built · 61 active (1 stopped by the target site’s robots.txt policy)
Open listings	6,147 — 3,718 with a specified region · 2,429 nationwide or delivery-type
Platforms with open listings	60
Listings held in the database	20,654 — listings 30 days past closing are auto-deleted, so cumulative throughput is higher
Exploration axes	17 provinces and their districts × 9 categories × 4 sort orders, plus search terms
Build period	About six weeks from the first commit on 30 June 2026

These figures are a measurement-date snapshot of continuously changing operational data. Navirang does not edit figures in a published article afterwards — doing so erases what that article measured and when. Changed values go out as a new article.

In summary, what Navirang performed on this project:

• Building the whole Reviewloger web service (design, information architecture, front end, back end)
• Building the automated collection system for campaign platform listings (62 adapters, 61 currently active)
• Automating normalisation and consolidation of differently structured platform data
• The continuous update structure of collect → review → publish → close → delete
• Building the region, category, search and sort exploration system
• Search engine structure (selective sitemap, noindex policy, nine structured data types)
• The AI search discoverability audit and measurement design

Still being measured — the numbers go in when they exist

AEO discoverability improvement results are not in this article. Once the same question set has been measured repeatedly before and after the work and the following metrics have actual values, they will be published as a separate article.

• Brand mention rate in ChatGPT, Gemini and Perplexity
• Discovery rate on general questions with no brand name
• The proportion of answers citing Reviewloger’s official URL as a source

The reason we do not write unmeasured values in advance is the same as the one set out in how to read AEO performance figures. A figure with no measurement conditions cannot be verified, and a figure that cannot be verified cannot be demanded of anyone else either.

Method and sources

Item	Detail
Analysis date	12 August 2026
Analysis tool	OpenAI ChatGPT (GPT-5.6 Sol) — AI-assisted research
Method	Real user question testing · service recommendation questions with no brand name · web search result comparison · competitor discovery path comparison · analysis of official site and external web signals · comparison of service fit against AI discoverability
Build scope verification	Reviewloger repository code analysis · production database public-query aggregation (12 Aug 2026)

This does not mean that OpenAI or ChatGPT certified, endorsed or officially recommended the service quality of Navirang or Reviewloger. ChatGPT was used as a tool for search result research and comparative analysis on this project.

A record of the same project written from the service operator’s point of view exists on the Reviewloger side — about the Reviewloger build project (Korean). This article is the record from the development and AEO delivery side, so the two do not duplicate each other.

This case was written by Navirang Co., Ltd., which built Reviewloger itself. It is not a third-party verified assessment, and there is no guarantee that what was observed here reproduces for another service. The scope statements and figures in the body are only values confirmed in the repository code and the production database, and unmeasured outcomes are not included.