Build and Deploy an Online Directory With Claude Code

Choose Your Directory Setup

Open an empty folder — or your existing project — in Claude Code. Pick your directory type first: the listing details and filters then suggest what fits it.

Build Your Directory Interface

Choose your niche, what each listing shows, the filters and who can add listings, and Claude Code builds the whole directory interface with realistic sample listings.

Build the interface for an online directory. This task builds the screens only, with realistic sample listings. Real data comes later. Directory type: {{DIRECTORY_TYPE}} Directory name: {{DIRECTORY_NAME}} What each listing shows: {{LISTING_FIELDS}} Extra listing details: {{EXTRA_FIELDS}} What visitors can filter by: {{FILTERS}} Who can add listings: {{SUBMISSIONS}} Visual style: {{DIRECTORY_STYLE}} 1. INSPECT FIRST Inspect this folder before changing anything. - If it is empty, create a new React + Vite + TypeScript project here, with client-side routing and a simple, well-organised structure. - If a project already exists, keep its framework, styling and components, and add the directory to it. Do not rebuild, rename or restructure working code, and do not touch unrelated pages. Tell me which case applies, then continue. 2. SAVE THE DIRECTORY SCOPE Add a "Directory" section to CLAUDE.md in the project root — create the file if it does not exist. Record the directory type, the name, the listing fields and which of them appear on cards, the filters, the categories you choose, who can add listings and the visual style. Every later task reads this section, so keep it short and accurate. Never write keys or passwords into it. 3. A DIRECTORY, NOT A MARKETPLACE The job is to help visitors discover and compare listings: browse → search → filter → open a listing. Do not add a cart, checkout, payments, buyer–seller messaging, bookings, a reviews platform or visitor accounts. Build only the fields and filters above. If one does not make sense for this directory type, tell me and leave it out. 4. PUBLIC PAGES - a directory home to browse listings, with the search box and the filters - category pages or a category filter — whichever fits this directory better - a page for each listing at its own clean address, for example /tools/claude, with richer details and the main action for this niche — such as Visit website, Contact, Get directions or Open resource - a Submit a Listing page — ONLY if visitors can submit listings Every button must do something real; leave out any action a listing has no data for. Add an About page only if it genuinely helps. No marketing pages. 5. LISTING CARDS Show only what matters at a glance — for example the name, the category and one key detail such as the pricing or the city. Do not pack every field into the card. 6. SEARCH AND FILTERS Build the search box, the filters above, removable active-filter chips, a Clear filters action, a result count and a helpful empty state, such as "No tools found — try removing a filter". They can work on the sample listings for now. No fake rankings: never label listings Best, Top or Most popular. 7. ADMIN AREA Build a separate owner area: a listing list with Draft and Published states (plus Pending if visitors can submit), a listing form with the fields above, a categories screen, and — only if visitors can submit — a review queue. The forms can stay local for now. Never pretend that something was saved. 8. CATEGORIES AND SAMPLE LISTINGS Choose 5 to 8 categories that fit this directory, and create 12 to 20 realistic sample listings across them. Prefer believable fictional names, use placeholder links such as example.com, and never invent contact details for real businesses. No lorem ipsum. Keep all sample listings in ONE clearly named module, shaped like real data, so a database can replace it later. 9. COMPONENTS Build the listing card, the filters and the listing page as reusable components. 10. DESIGN Apply the visual style and the directory name. Mobile browsing must be excellent: a search box within easy reach, filters in a drawer or sheet on phones, and cards readable at a glance. Keep it calm: no decorative gradients or glows, and no fake statistics. 11. RUN IT Start the development server and give me the local address. When finished, report: - whether you created a new project or extended an existing one - the public pages and the admin screens - the categories, and which fields appear on cards - where the sample listings live - anything you left out, and why

What kind of directory are you building?

Directory name

ToolScout

Who can add listings?

Directory style

What should each listing show?

Any extra details? (optional)

Free trial, launch date, languages...

What should visitors filter by?

Claude Code saves your choices in the project's CLAUDE.md file, so every later prompt builds only what you picked.

Check the Directory Interface

Open the local address Claude Code gives you:

The directory shows the sample listings as cards

Cards show only the key details at a glance

The search box and your filters are there

A listing page opens at its own address with its main action

The admin screens show the listings, the listing form and categories

Submit a Listing exists only if you chose visitor submissions

Browsing works well at phone width

Ask Claude Code for any change now — the interface is easiest to adjust before real data arrives.

Expected result

You should now have a polished directory interface with realistic sample listings, search/filter UI, listing pages, and the appropriate owner/submission screens.

Connect Supabase

If this project is already connected to the right Supabase project, reuse it — don't create a second one.

Open Supabase

https://supabase.link/r4gdwhi

Create a new project if you don't have one Open the project's Connect panel Copy the Project URL and the Publishable key Ask Claude Code which environment variable names this project uses, then add both values locally

IMPORTANT

The browser app only needs the Project URL and the Publishable key. A Secret key belongs only in a trusted server environment, and only where one is genuinely needed — never in browser code and never committed to GitHub.

Create Your Admin Account

Visitors never need accounts — only you sign in. Create two accounts: one for you with your real email address, which becomes the admin, and one test account that proves signing in alone grants nothing.

Supabase Authentication Users

Click Add user, then Create new user Enter the email address and a password Keep Auto Confirm User on, then create the user Repeat for the test account

Then turn off public sign-ups

Nobody else needs an account. Turn off Allow new users to sign up and save.

Supabase Authentication Sign In / Providers

Store Your Listings in Supabase

Use this prompt in Claude Code. It gives you one SQL block to review and run.

Store the Directory Listings

Create the listing and category data for your niche, add the owner's sign-in, and keep drafts private from the start.

Turn the directory into a real database-backed directory with Supabase. This task stores the listings and adds the owner's sign-in; the admin dashboard comes next. Read the "Directory" section of CLAUDE.md first. It records the listing fields, the filters and who can add listings — build only what it lists. Inspect the project first. If it is already connected to Supabase, reuse that project and its client — do not create a second one. Use the current Supabase terms: the Project URL and the Publishable key. Never put a Secret or service-role key in browser code, and never print secret values. 1. ENVIRONMENT Read the Project URL and the Publishable key from environment variables, using this framework's naming. Tell me the exact names, list them in .env.example without values, and make sure .env is git-ignored. 2. OWNER SIGN-IN Visitors never need accounts. Add email and password sign-in for the admin area only — no public sign-up page — and protect every admin route. - Store who is the admin in the database, for example a profiles table with a role or an admins table keyed by the auth user id. Nobody can make themselves admin. Never decide it from user_metadata, local storage, the URL or anything else the browser controls. - Make MY account the admin with ONE reviewed SQL statement. - Being signed in is not the same as being the admin: my test account must get nothing. 3. DATA MODEL Build the tables around the fields in CLAUDE.md — do not force a generic schema: - listings: the chosen fields as real columns, plus id, slug, status, created_at and updated_at - categories: a name and a slug. One category per listing, unless this directory genuinely needs several — then a listing-category table - tags only if the fields include them - status: draft or published — plus pending if visitors can submit - only if visitors can submit: the submitter's name and email in a separate private table that only the admin can read — never on the public listing row Use generated ids as the identity. Create nothing unrelated. 4. SLUGS Every listing gets a clean, unique slug for its address. Generate it from the name when the listing is created, keep it stable when the name changes, and handle duplicates — for example acme-2. 5. IMAGES — only if the fields include a logo, photo or cover Create a Storage bucket for listing images that the public can read and only the admin can write to. Allow image types only, with a sensible size limit. 6. WHO CAN READ WHAT Turn on Row Level Security on every table immediately. - Anyone can read PUBLISHED listings, their categories and tags. Drafts and pending listings are visible only to the admin — the database enforces this, not a frontend filter. - Only the admin can create, change or delete listings and categories. Use one trusted database check for "is this account the admin". 7. REAL DATA Replace the sample listings with real queries, and remove the sample module. Listing pages load by slug; an unknown or unpublished slug shows a clear "not found" page. Give me ONE reviewed SQL seed that recreates the categories and sample listings in Supabase — mostly published, plus one draft — so the directory keeps working while I add real listings. Ask me for the two accounts' email addresses — never their passwords. Show loading, empty and error states, and never show raw database errors. Give me: 1. The environment variable names 2. The tables and what each holds 3. How the admin is stored and protected 4. The read and write rules, table by table 5. ONE reviewed SQL block to run in the Supabase SQL Editor: the tables, the rules, the image bucket if needed, the admin statement and the seed 6. Anything that blocks the next step Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not build the admin forms yet — they come next.

Review the SQL, then run it in your Supabase project. It creates the directory tables, makes your account the admin and adds the sample listings.

Supabase SQL Editor

Visitor: the directory shows the published sample listings

Visitor: the draft listing doesn't appear, even by its address

Visitor: a listing page opens at its own address

Admin: sign in and reach the admin area

Test account: the admin area is refused

Build the Admin Dashboard

Build the Admin Dashboard

Create, preview, publish and delete listings, manage categories and upload images from your own dashboard instead of Supabase.

Build the admin dashboard, so I run the whole directory inside the app. I must never need the Supabase dashboard for daily work. Read the "Directory" section of CLAUDE.md first, and build only for the fields it lists. Reuse the admin screens you already built. Every write goes through the database rules, which allow admin actions only. No Secret or service-role key in the app. 1. ADMIN ONLY Only the admin account reaches the admin area. Signed-out visitors and my test account see the sign-in screen or a "no access" page, and the database refuses their requests anyway. 2. LISTINGS - a list of every listing with its status, and a quick way to find one - create and edit a listing with the chosen fields - Preview: see a draft exactly as its public page will look - Publish and Unpublish - Delete, only after a clear confirmation — this also removes its images 3. CATEGORIES Create, rename and delete categories. Never delete a category that still has listings without asking me what should happen to them. 4. IMAGES — only if the fields include them Upload or replace a listing's images from its form, with a preview, and remove the old file when an image is replaced. 5. SAFE CONTENT Accept only http and https links. Show every text field as plain text — never render HTML from a listing. Validate required fields and sensible lengths. 6. FORMS Prevent double submission, show clear success and error messages, and never show raw database errors. Keep every screen usable on a tablet and a phone. Give me ONE reviewed SQL block for any new rules, to run in the Supabase SQL Editor. Never drop tables, columns or data. When finished, report: - the admin routes - how the admin check works in the app and in the database - what Preview shows - what deleting a listing removes

Run any SQL it gives you in the SQL Editor. Then, as the admin:

Create a listing and preview it

Publish it — it appears in the public directory

Edit it — the public page updates

Unpublish it — it disappears publicly

Add a category and use it

Delete a test listing — you're asked to confirm first

Expected result

The owner can now create and publish a real listing through the directory's admin dashboard, and it appears publicly.

Build Search and Filters

Make Search and Filters Work

Search the right fields, combine your filters, keep them in the address bar, and show related listings on every listing page.

Make search and filters genuinely useful. Read the "Directory" section of CLAUDE.md first, and build only the filters it lists. Search and filter in the database with focused queries and sensible limits — never download every listing to filter it in the browser. Do not add Algolia, Elasticsearch or any other search service. 1. SEARCH Search the fields that make sense for this directory — for example the name, the short description, the category and the tags. Never search internal fields such as the status. Make it case-insensitive and tolerant of extra spaces, using the simplest reliable approach for this size: a case-insensitive match across those fields, or Postgres full-text search with an index if the directory will grow large. An empty search shows every published listing. 2. FILTERS Implement exactly the filters in CLAUDE.md. Different filters narrow the results together; picking two values of the same filter widens it — for example Free or Freemium. Offer only values that published listings actually have. 3. ADDRESS BAR Keep the search and the filters in the URL — for example ?q=writing&category=design&pricing=free — so a search can be shared, survives a refresh, and Back returns to the previous results. Use the router's normal query handling, not a new state library. 4. RESULTS Show the result count, the active filters with a way to remove each one, a Clear filters action, and a helpful empty state — for example "No tools found. Try removing a filter or searching for something else." Once there are more than a few dozen results, show them in pages or with Load more. 5. SORTING — only if it helps this directory At most Newest and Name. Never invent Best, Top or Most popular rankings without real data behind them. 6. RELATED LISTINGS On each listing page, show up to four related published listings that share its category first, then its tags or location. Never the listing itself, never random entries, and hide the section when nothing is related. Give me ONE reviewed SQL block for any index or search function this needs, to run in the Supabase SQL Editor. When finished, report: - which fields search covers, and how - how the filters combine - what the URL looks like for a filtered search - how related listings are chosen

Run any SQL it gives you in the SQL Editor.

Test Search and Filters

Browse as a signed-out visitor:

Search for a word from a listing's name — it appears

The same search in different upper and lower case gives the same results

Combine two filters — the results narrow correctly

Refresh — the search and filters stay

Press Back — the previous results return

Clear filters brings every listing back

A search with no matches shows a helpful empty state

A listing page shows related listings that genuinely match

Expected result

Visitors can now search, filter, open listings, and discover related entries using real directory data.

Set Up Your Listing Workflow

The prompt follows your Step 1 choice: a moderated Submit a Listing flow, or a polished owner-only workflow.

Finish the Listing Workflow

Add moderated visitor submissions if you chose them, or tighten your owner-only admin workflow if you didn't.

Finish the listing workflow. Read the "Directory" section of CLAUDE.md first — it records who can add listings. Follow ONLY the part below that matches. IF ONLY I ADD LISTINGS Do not build any public submission form, route or database path. Instead, walk through my admin workflow end to end — create, preview, edit, publish, unpublish and delete — and fix whatever gets in the way. Keep the changes small. IF VISITORS CAN SUBMIT LISTINGS FOR APPROVAL 1. SUBMIT A LISTING Add a public Submit a Listing page with the listing fields from CLAUDE.md, plus the submitter's name and email for follow-up. Visitors do not need an account. Never show internal fields such as the status. 2. PENDING REVIEW Every submission is saved as Pending and never appears publicly until I approve it. Use the smallest secure path the architecture supports — for example one trusted database function that validates the input and forces the Pending status. Do not give anonymous visitors broad table permissions: they cannot read, list, change or delete any submission, including their own. 3. REVIEW QUEUE Show pending submissions in the admin dashboard, newest first. Let me review one, correct any field, approve it (which publishes it) or reject it. Rejecting either deletes the submission or keeps it hidden as rejected — choose the simpler one and tell me. 4. BASIC ABUSE PROTECTION Check required fields, sensible lengths and http or https links on the trusted path — not only in the browser. Store and show everything as plain text; never render submitted HTML. If the fields include an image, accept one image of an allowed type and size into a private area only I can see until approval. Add a hidden honeypot field, or a simple per-visitor limit if the architecture supports it. No CAPTCHA service. 5. DUPLICATES Flag obvious duplicates for me in the review queue — for example the same website or the same name as an existing listing. Do not claim perfect detection. 6. CONFIRMATION After submitting, show a clear "Thanks — your listing is waiting for review" message. Never suggest it is already live. Give me ONE reviewed SQL block for any new tables, rules or functions, to run in the Supabase SQL Editor. Never drop tables, columns or data. When finished, report which part you followed, and: - for owner only: what you fixed in the admin workflow - for submissions: the submission path, what a visitor can and cannot do, and how approval and rejection work

Run any SQL it gives you in the SQL Editor.

Check Your Listing Workflow

Run the checks for the setup you chose:

Owner only: create, preview, edit and publish a listing

Owner only: unpublish it, then delete it

Submissions: submit a listing while signed out

Submissions: it doesn't appear publicly

Submissions: it waits as Pending in your review queue

Submissions: approve it — it goes live

Submissions: reject another — it stays private

Submissions: a submission with a bad link is refused

Expected result

With submissions: new submissions enter a review queue and become public only after you approve them. Owner only: you fully manage the directory through the protected admin area.

Test Browsing, Search and Filters

Browse as a signed-out visitor:

Published listings appear

Draft listings stay hidden

Listing cards show the right details

Listing pages load correctly

A wrong listing address shows a helpful not-found page

Common searches return the right listings

Search ignores upper and lower case

An empty search shows every listing

A search with no matches shows the empty state

Each filter works on its own

Filters combine correctly

Clear filters works

Filters survive a refresh

Back returns to the previous results

Test the Admin, Submissions and Images

Skip any check for a feature your directory doesn't have.

Signed out or as the test account: the admin area is refused

Admin: create a listing

Admin: edit it

Admin: publish and unpublish it

Admin: deleting asks for confirmation

Admin: categories work

Submissions: a visitor can submit a valid listing

Submissions: it doesn't appear publicly yet

Submissions: the admin sees it as Pending

Submissions: approving publishes it

Submissions: rejecting keeps it private

Submissions: bad links and oversized text are refused

Images: a valid image uploads and shows

Images: a file that isn't an image is rejected

Images: a listing without an image shows a clean placeholder

Test on a Phone and Fix What Failed

Check the phone experience, then let Claude Code check the database directly:

Phone: search and filters are easy to use

Phone: listing cards are easy to read

Phone: listing pages fit the screen

Phone or tablet: the admin area is usable

Verify and Fix the Directory

Prove the access rules directly in the database as a signed-out visitor and a non-admin account, then fix only the checks that failed.

Verify this directory at the database level, then fix what failed. Read the "Directory" section of CLAUDE.md first, and test only the features it records. These manual checks failed: {{FAILED_CHECKS}} 1. DATABASE CHECK Use a temporary LOCAL-ONLY script with the project's normal Supabase client and the Publishable key. Do NOT use the Secret or service-role key: it skips every access rule, so the test would prove nothing. Ask me to put the test account's password in local, uncommitted environment variables. Never commit passwords, never put them in source code and never print them. As a SIGNED-OUT visitor, try to: - read draft or pending listings, including by their exact slug or id - read submitters' names or emails - create, change or delete a listing or a category — except through the submission path, if submissions are on - use the submission path to publish directly, set a status or save a link that is not http or https - upload, replace or delete listing images As the TEST ACCOUNT, signed in but not the admin: try the same admin actions. Expected: refused — an error, no rows returned or zero rows changed. Re-read afterwards to confirm nothing changed. As the ADMIN: create, edit, publish and delete a test listing. Expected: it works. Remove it afterwards. 2. SECRETS Search the source code and the built files. Only the Supabase Project URL and Publishable key may appear. 3. FIX Find the real cause of each failed check — mine and yours — and fix it at its source. Keep every fix small: no redesign, no new features and no rewrites of working code. Run the database check again after any fix. Remove the script afterwards and do not commit it. Return exactly one: DIRECTORY READY or: NEEDS ATTENTION If NEEDS ATTENTION, give me any corrected SQL to run, list what still fails, and test again once I confirm the SQL has run.

Which checks failed?

The pricing filter ignores Freemium. The filter drawer covers the results on a phone...

Continue when Claude Code reports DIRECTORY READY. Its report confirms:

Signed-out visitors can't change listings or read drafts, pending listings or submitter details

The test account can't do anything only the admin can

No secret keys reach the browser

Prepare Listing Pages for Search Engines

Prepare Listing Pages for Search Engines

Give every published listing its own title, description and preview, and add a sitemap — using a small server, because browser-only tags aren't enough.

Prepare the directory's public pages for search engines and link previews, without turning this into a full SEO project. Read the "Directory" section of CLAUDE.md first. Only real, published listings may become indexable pages. Do not create thin pages — no page per search or filter combination. 1. THE HONEST LIMIT Search engines and link previews often read only the first HTML a page returns, so tags set later by browser JavaScript are not enough on their own. Each listing's address must return its own metadata from the server. 2. A SMALL PRODUCTION SERVER Use one small Node production server — for example Express — as the app's entry file. It serves the built app, falls back to the app for client-side routes, and: - for a listing address: looks up the PUBLISHED listing by its slug with the Supabase Project URL and Publishable key, and returns the page with that listing's own title, meta description, canonical URL and Open Graph title, description and image. Escape every value you insert. An unknown, draft or pending slug returns a real 404 status, a noindex tag and the app's not-found page. - /sitemap.xml: the directory home, real category pages if they exist, and every published listing's address — built from the database and cached for a few minutes - /robots.txt: allows the public directory, disallows the admin area and points to the sitemap Build every absolute URL from a SITE_URL environment variable, never a hard-coded address. 3. IN THE APP - a unique title and meta description for the home, category and listing pages - one h1 per page — the listing's name on its own page - listing cards use real links (a href), so crawlers can follow them - search and filter views point their canonical URL at the main directory page - the admin area and the Submit a Listing page carry noindex 4. STRUCTURED DATA — only if it truly fits Add JSON-LD only when a type genuinely matches this directory — for example LocalBusiness for local businesses — and only with real fields. Otherwise skip it. 5. CHECK IT Run the production build with the server locally, give me its address, and show me the returned HTML head for one listing page, the sitemap, and the status code of an unknown listing. When finished, report: - the server's entry file and how Hostinger should run it - what one listing page's head contains - what the sitemap includes and excludes - anything the SPA still cannot do for SEO

Then open the local address Claude Code gives you and check:

View a listing's page source — its own title and description are there

/sitemap.xml lists your published listings and no drafts

/robots.txt points to the sitemap

An unknown listing address shows the not-found page

Expected result

The directory is functional, secure enough for its intended workflow, mobile-friendly, and its real published listing pages are ready for visitors and search engines.

Prepare and Deploy the Directory

Prepare the Directory for Production

Build the directory for production, remove development leftovers, keep secrets out, and get the exact Hostinger settings.

Prepare this directory for production on Hostinger, as a Node.js Web App deployed from GitHub. Read the "Directory" section of CLAUDE.md first. Do not add features, and never print secret values. 1. BUILD Run the production build and fix anything that fails. 2. REMOVE DEVELOPMENT CODE Remove anything left from development in the code: leftover sample listings, test-only scripts, debug logging and any hard-coded test account. Sample listings in the database stay until I remove them myself. 3. NO SECRETS IN THE APP Search the source code and the built files. Only the Supabase Project URL and Publishable key may appear — no Secret or service-role key and no passwords. Make sure .env is git-ignored and never committed, and that .env.example lists the variable names without values. 4. ENVIRONMENT VARIABLES List the exact environment variable names Hostinger needs — including SITE_URL for the server — and whether each is needed at build time, at runtime or both. 5. ROUTING The production server from the search-engine step must serve the app, fall back to it for client-side routes, and return listing metadata. Confirm that refreshing or directly opening a listing, a category or an admin page loads correctly, and that nothing points at localhost. 6. HOSTINGER SETTINGS Tell me what to confirm on Hostinger's deploy screen: the framework preset, the build command, the output directory, the Node version and the entry file that starts the server. Do not commit or push — I will review first. Report: - the build result - what you removed - the environment variable names - the Hostinger settings - anything that blocks deployment

Push the project to GitHub with Claude Code or your normal GitHub workflow. If it already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the directory's repository Confirm the framework, build settings and entry file Claude Code gave you Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Add the Supabase Project URL and Publishable key under the names your project already uses. Private server keys stay private — never rename one to a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Point Everything at Your Live Address

Listing pages, the sitemap and admin sign-in all need your real address.

1. Set SITE_URL in Hostinger

Add SITE_URL with your live address — for example https://yourdirectory.com — to the app's environment variables in Hostinger, then redeploy.

2. Add your live address to Supabase

Set the Site URL to your live Hostinger address and add it to the Redirect URLs.

Supabase Authentication URL Configuration

Test the Live Directory

Open your live address and check. Skip any check for a feature your directory doesn't have.

The directory loads on your Hostinger address

Published listings appear

Search works

Filters work

A listing address opens directly

Refreshing a listing page works

Admin: sign in

Admin: create, edit and delete a test listing

Listing images load

Submissions: a visitor can submit a listing

Submissions: it stays private until you approve it

A listing's page source shows its title, description and live address

The directory works on a phone

Verify the Live Directory

Check the deployment, listing pages and metadata, the sitemap, access rules and secrets on the live directory.

Perform a focused production check of this directory, now live on Hostinger. Read the "Directory" section of CLAUDE.md first. Do not add features and never print secret values. Do not claim to inspect Hostinger or Supabase settings you cannot see — ask me for the live address, and ask me to confirm specific settings. 1. DEPLOYMENT - the deployment succeeded from the intended repository and branch - the required environment variables are set, and SITE_URL is the live address - no secret files are in the repository 2. PAGES - listing addresses open directly and after a refresh - each listing page returns its own title, description, canonical URL and Open Graph tags, all using the live address - an unknown listing returns a 404 - /sitemap.xml lists only published listings, and /robots.txt points to it 3. ACCESS - admin sign-in works on the live address - run the signed-out and test-account database checks against the production Supabase project, with the Publishable key — never the Secret or service-role key - drafts, pending submissions and submitter details stay private 4. SECRETS - no secret key appears in the live site's code or network requests Return exactly one: DIRECTORY LIVE or: NEEDS ATTENTION If DIRECTORY LIVE, summarize the live address, listings, search and filters, listing pages and metadata, the admin workflow and access protection. If NEEDS ATTENTION, list only launch blockers.

Continue when Claude Code reports DIRECTORY LIVE, confirming:

No secret keys appear in the live site's code or network requests

Before real visitors arrive

Unpublish or delete the sample listings in your admin dashboard, then delete the test account in Supabase. Keep your own admin account.

Supabase Authentication Users

Expected result

Your searchable online directory is live on Hostinger with real listings, useful filters, dedicated listing pages, and a protected admin workflow.