Blog / Engineering

SEO Lessons From Fixing Our Own Site

Duplicate FAQ markup, the wrong thumbnail in Google, template pages nobody clicked and a path our edge refused: what we found on mythex.ai and fixed.

Mythex Team · 2026-09-29 · 5 min read

We spent a few days reading our own site the way a search engine does, and found six things worth fixing. Every page was declaring two FAQ blocks, Google was using a decorative background glow as our thumbnail, a set of template pages were ranking for searches they didn't answer, and a new section of the site was blocked by our own edge on staging. None of it was dramatic. All of it was quietly costing us visibility.

The site in one paragraph

mythex.ai is a single-page app that we prerender at build time: a script walks every route, writes a static HTML file for it, and injects the page's title, description and structured data (the JSON-LD block that tells search engines what a page is — see what is structured data). Most of what follows lives in that prerender step, because that is the HTML a crawler actually reads.

1. Every page claimed to be the FAQ page

Symptom. Our HTML template carried a site-wide FAQPage block in its structured data, with its URL pointing at /faq. Prerender then added each page's own FAQPage on top. So every page on the site shipped two — and our privacy policy was telling Google it was the FAQ page.

Why it matters. Google expects at most one FAQPage per page. A second one that points somewhere else is the kind of thing that gets a page's markup discounted, not just ignored.

Fix. The global block is gone. Each page's FAQ markup now comes from one place, including /faq itself, which builds it from the full list of questions. Pages that have no FAQs now declare none, which is the honest answer. And prerender fails the build if any page ever carries more than one FAQPage again. A rule that only lives in someone's memory gets broken; a rule the build enforces doesn't.

2. Google used the wrong picture for us

Symptom. In search results, the Mythex thumbnail was the soft pulsing glow behind our homepage hero — a decorative background image — instead of our share card.

Why it happened. We never told Google which image represented a page, so it picked one it found.

Fix. Two sides of the same problem:

  • Say which image is the page's. The homepage now has a WebPage node with a primaryImageOfPage pointing at the share card, and every prerendered page's structured data carries its own image (the page's share image, or the default one).
  • Hide the decoration. The background images are now disallowed in robots.txt and served with a noindex, noimageindex header, so they stay out of image search and thumbnails.

3. Search engines only knew our logo

Our Organization markup had a name, a logo and some social links — branding, nothing else. Search engines build a company's knowledge panel from registry-style facts, so we added the ones from our trade licence: legal name, founding date, founder and registered address. We deliberately left the phone number out.

4. Template pages answered the wrong question

Symptom. Search Console showed three template pages collecting impressions and no clicks. One ranked for "content strategist portfolio" and its variants, one for "best italian restaurant website design", one for a cluster around "agile board" — half of those searches included the word "free". Positions ranged from the mid-20s to the 50s.

Why. Each page answered a different question from the one asked. Someone who wanted to see what good Italian restaurant design looks like landed on a page selling them a builder.

Fix. Each of the three now has a section written for the search rather than for the product, a title and description in the words people type, and FAQs worth the markup they already emitted.

The same commit fixed a quieter problem. The "related templates" block took the first four templates in a category, so every portfolio template pointed at the same four portfolios, and the rest of that category had no internal links at all. We replaced it with a ring ordered by subcategory: every template page now gets exactly four links in and four out. The prerendered HTML also prints those links now — before, they only existed after JavaScript ran, which a crawler may never do.

5. Telling Bing about new pages the moment they deploy

Google ignores IndexNow, a protocol for pinging search engines when a URL changes. Bing, Yandex and Seznam use it — and Bing's index is what ChatGPT search reads. An AI app builder that AI assistants can't find is a particular kind of failure.

The obvious approach, submitting the whole sitemap on every deploy, is how a key gets throttled, and most deploys change nothing a search engine cares about. So a script compares the sitemap the site is serving right now with the one just built and submits only the difference.

Two details made it work:

  • Snapshot before you deploy. The baseline has to be captured before the new build goes live. Afterwards, the "live" sitemap is already the new one and every diff comes back empty.
  • New pages only, for now. Our sitemap has no lastmod dates, so the script announces new pages but not rewrites. Stamping every URL with the build date would mark the entire site as changed on every deploy — exactly the spam we were avoiding.

It runs on production deploys only and never fails the build: by the time it runs the site is already live, and a search engine ping isn't worth a red deploy.

6. Our own edge said "not found"

When we launched the /ai pages (more on those in a landing page for every kind of business), staging showed "Not found" for all of them while the static host served them fine.

The service in front of our marketing hosts only forwards an allowlist of paths; anything else gets a hard 404. /ai was new and wasn't on the list. We added /ai and /ai/*, with a test that asserts they pass. A small bug, but exactly the kind that makes a new section invisible to crawlers without anyone noticing.

What we took from it

  • Read the HTML a crawler reads. Most of these were invisible in a browser and obvious in the prerendered file.
  • Turn SEO rules into build checks. "One FAQPage per page" is now enforced, not remembered.
  • Tell search engines what you mean. If you don't say which image or which facts represent you, they will guess.
  • Search Console tells you which question people asked. Impressions without clicks usually mean the page answered a different one.
  • Submit differences, not everything. Pinging only what changed keeps you on the right side of rate limits.

If you're doing the same for a site you built, our guides on SEO for AI-built websites and setting up Google Search Console cover the basics.

Keep reading

  • A Failed Republish Never Deletes a Working Backend — A failed republish could delete an app's live API, or leave its broken new version running. Three fixes to how Mythex undoes a publish that goes wrong.
  • A Landing Page for Every Kind of Business — Search for a booking system for a dental clinic or a website for a bakery and land on a Mythex page written for that business, with a prompt ready to build it.
  • Alerts That Fire Once, Not Once per Server — A once-a-day alert reached us five times in one afternoon. Why in-memory dedupe breaks with two servers and a deploy, and how shared state fixed it.
  • Moving to Bigger Workspaces Without Making Anyone Wait — A quarter of our workspaces were stuck at 1 GB after we moved to 2 GB. Our first fix made one person wait seven minutes. What we changed, and changed again.
  • Billing Databases by What They Actually Use — We used to estimate each app's database cost, and the estimate was wrong both ways. Now every database is billed from measured usage, hour by hour.
  • Catching Apps That Crash Right After Publishing — Three publishes passed our health check while their API crashed seconds into every boot. The cause: counting crashes in a list capped at five entries.

Start building free · Templates · Docs