Forem: Joel

I'm losing my own brand SERP to 3rd-party articles. Here's the JSON-LD stack I'm shipping to claw it back.

Joel — Wed, 22 Apr 2026 06:52:27 +0000

The problem I'm still losing at

Search my app's name on Google and the first results aren't my site. They're other people's articles about it. Directories, aggregators, a Reddit thread, a Medium post. The actual product, CandleDojo, sits somewhere below the fold.

This is normal for a young domain. Google doesn't have enough signal that "candledojo" the query = "candledojo.app" the entity. Every 3rd-party write-up outranks the site itself because those domains are older, have more backlinks, and carry more topical weight than a six-month-old app.

I'm not done fixing this, but one of the levers I'm pulling is structured data. Specifically JSON-LD. And not just the basics that SEO checklists tell you to ship. There's a specific stack that matters when you're trying to:

Resolve as a clean entity in Google's Knowledge Graph
Win rich result eligibility on your own content pages
Get cited by AI tools (Perplexity, ChatGPT search, Claude) when they answer questions in your niche

Here's the stack I ship on every page of CandleDojo, what each schema actually does, and what I'd skip if I were starting from scratch.

The mental model: one helper, many schemas

All my JSON-LD lives in src/lib/structured-data.ts. It's one file of pure TypeScript helpers that return plain objects. Each helper is a schema builder. I inject them via <script type="application/ld+json"> tags from either the root layout (site-wide schemas) or page components (page-specific schemas).

No CMS, no plugin, no markup hacked into <Head>. Just typed functions.

export function buildBreadcrumbJsonLd(items: BreadcrumbItem[]) {
  return {
    '@context': 'https://schema.org',
    '@type': 'BreadcrumbList',
    itemListElement: items.map((item, index) => ({
      '@type': 'ListItem',
      position: index + 1,
      name: item.name,
      ...(item.item ? { item: item.item } : {}),
    })),
  }
}

That shape repeats for every schema. Helper in, object out, inject once. Below is what I inject where.

Schema 1: Organization + WebSite in the root layout (the entity anchor)

This is the single most important one for branded search. If you do nothing else, do this.

In src/app/layout.tsx, I run buildOrganizationJsonLd() once per request. It emits:

{
  '@context': 'https://schema.org',
  '@type': 'Organization',
  name: 'CandleDojo',
  alternateName: 'Candle Dojo',
  url: 'https://candledojo.app',
  logo: 'https://candledojo.app/favicon.svg',
  description: '...',
  contactPoint: [{ '@type': 'ContactPoint', contactType: 'customer support', ... }],
  sameAs: [
    'https://x.com/candledojo',
    'https://discord.gg/...',
    'https://www.youtube.com/@candledojo',
    'https://www.reddit.com/user/CandleDojo/',
  ],
}

Two things matter here more than anything else.

sameAs. Every owned profile, listed. X, YouTube, Discord, Reddit, GitHub if public, dev.to author page. This is how Google connects your brand name to a set of identities it can cross-verify. The more consistent profiles you list, the faster "candledojo" becomes a resolved entity.

alternateName. Search users type "candle dojo" as two words too. Telling Google both variants point at the same entity saves you a ranking split.

I pair Organization with a separate WebSite schema on the homepage. Same idea, narrower scope: here's the site, here's its name, here's the canonical URL. Two entity anchors reinforce each other.

Schema 2: WebApplication on the homepage

If you're an app, not a blog, tell Google. A content-only schema stack is why so many SaaS tools get treated as articles.

{
  '@context': 'https://schema.org',
  '@type': 'WebApplication',
  name: 'CandleDojo',
  applicationCategory: 'EducationalApplication',
  operatingSystem: 'Web',
  offers: { '@type': 'Offer', price: '0', priceCurrency: 'USD' },
}

applicationCategory and operatingSystem unlock app-style rich results eligibility. offers is where you declare freemium or paid tiers. If you have honest review volume, add aggregateRating. I don't yet, so I leave it off. Stuffing fake ratings is the fastest way to earn a manual action.

Schema 3: BreadcrumbList on every nested route

The laziest high-leverage schema. Takes 10 lines per route, gives you rich breadcrumb links in SERPs, and tells Google exactly how your site is structured.

On an insights page, I inject:

buildBreadcrumbJsonLd([
  { name: 'Home', item: 'https://candledojo.app' },
  { name: 'Insights', item: 'https://candledojo.app/insights' },
  { name: report.title, item: canonicalUrl },
])

Every nested route on CandleDojo does this: /patterns, /guides, /insights, /vs, /tools. The App Router makes it trivial because each route file already knows its own URL.

Schema 4: Article + HowTo on guide pages (the combo)

For long-form pages that explain something, Article plus HowTo is the pairing.

Article gets you eligibility for the Top Stories carousel, date-surfaced results, and author byline display. HowTo gets you steppable rich results (though Google has narrowed the visual treatment, the entity signal still matters).

My buildArticleJsonLd() helper spits out:

{
  '@context': 'https://schema.org',
  '@type': 'Article',
  headline,
  description,
  url,
  mainEntityOfPage: url,
  inLanguage: 'en',
  author: { '@type': 'Organization', name: 'CandleDojo', url: '...' },
  publisher: buildPublisher(),
  datePublished,
  dateModified,
  image: [image],
  keywords,
  about: about.map(name => ({ '@type': 'Thing', name })),
  articleSection: section,
}

Two details people mess up:

mainEntityOfPage must equal the canonical URL. Not a tracking param version, not a trailing-slash mismatch. Google will silently ignore mismatched entities.
dateModified should update when the page actually changes. Don't set it equal to datePublished forever. Freshness signals help.

For the HowTo pair, I only emit it when the page genuinely has steps. Don't synthesize steps just to qualify. Google's Rich Results Test will accept it, then Google Search itself will quietly not surface it and you'll have wasted markup.

Schema 5: DefinedTerm on glossary and pattern pages

This one is underused and it's my favorite.

I have 12 candlestick pattern pages on CandleDojo (hammer, doji, engulfing, etc.). Each page is essentially a definition plus a guide. DefinedTerm is the schema built for exactly this:

{
  '@context': 'https://schema.org',
  '@type': 'DefinedTerm',
  '@id': url,
  url,
  name: 'Bullish Engulfing',
  description: '...',
  inDefinedTermSet: 'https://candledojo.app/patterns',
  about: [{ '@type': 'Thing', name: 'candlestick patterns' }],
}

Why I like it for AI citations specifically: LLMs building answers for "what is a bullish engulfing pattern" prefer to cite sources that expose structured definitions. DefinedTerm is cleaner than Article for single-concept pages and reduces the chance of the crawler pulling the wrong paragraph.

inDefinedTermSet groups all your terms under one glossary URL. It's the schema equivalent of saying "this term is part of my taxonomy, here's the index."

Validate and measure

The boring but critical part.

Google Rich Results Test. Run every page type through it after shipping. It will tell you what it parsed and what it rejected. Screenshot the detected schemas list for your own records.
GSC Enhancements. After ~2 weeks, Google Search Console will populate Enhancement reports for each schema it found (Breadcrumbs, Sitelinks, Logo, etc.). If a schema doesn't show up, it wasn't parsed at scale.
Brand query panel. GSC Performance, filter query = your brand name. Watch impressions and average position for the branded term specifically. That's your scoreboard.

For AI citations, there's no dashboard. I just periodically run two queries in Perplexity and compare.

The first is a branded query: "what is candledojo". This tells me whether LLMs have resolved my brand as a distinct entity yet. Ideally the top answer cites candledojo.app directly.

The second is a category query: "best candlestick pattern trainer" or "best trainer app for reading price action". This tells me whether my pages show up when someone is not already looking for me by name. That's the harder win and the one that drives new traffic.

Branded citation means entity resolution is working. Category citation means topical authority is starting to stick. Both matter. Right now I get intermittent branded citations and almost zero category citations. The goal of stacking DefinedTerm, Article, and HowTo across my content pages is to move that second needle.

What I'd skip

FAQPage schema for non-support pages. Google nerfed it in 2023. It's still parseable but only surfaces on government and health sites now. Waste of markup on a product page.
Product schema for SaaS. Use WebApplication or SoftwareApplication instead. Product is for physical goods and triggers price-snippet rules that don't map cleanly to software.
Over-nesting. Don't inline your Organization inside every Article's publisher. Reference it by @id where you can, otherwise you balloon the JSON-LD weight and Google starts dropping payloads.
Review schema you don't control. If testimonials aren't from a verifiable source, leave them out. The risk of a manual action outweighs the rich result.

Closing

Structured data isn't going to single-handedly beat an aggregator that's been indexed since 2019. What it does is stack entity signals so that every page on your site tells the same story: this brand, this URL, these topics, this category.

I'm still losing my brand SERP today. Every week I check GSC, and every week the gap is a bit smaller. The JSON-LD stack above is one of the levers I'm pulling. The other is just shipping more content that gets linked with my brand name as anchor text. That's partly why I'm writing this post.

If you want to see the full schema stack live, pull up CandleDojo and view source. Everything in <script type="application/ld+json"> is the output of one of the helpers above. Copy what's useful.

And if you're fighting the same branded-SERP problem, drop the schemas that worked for you in the comments. I want more data points.

How I’m Building SEO + GEO for CandleDojo, a Chart-Reading Trainer

Joel — Tue, 31 Mar 2026 17:09:15 +0000

Hi there!

I’ve been working on CandleDojo, a browser-based chart-reading trainer for traders.

The product idea was always pretty clear in my head:
help traders get structured reps reading historical charts, recognizing candlestick patterns in context, and improving chart-reading skill without turning practice into random screen time.

But I realized something uncomfortable:

the product made much more sense when I explained it than when the website explained it.

That is a problem for normal SEO, and it is also a problem for GEO.

If someone searches Google for a candlestick practice tool, a chart-reading trainer, or a way to practice price action, the site needs to make that obvious.

And if someone asks ChatGPT, Claude, Perplexity, or Google AI something like:

what’s a good tool for practicing chart reading?

then CandleDojo needs to be understandable enough to be suggested as an answer.

So I started rebuilding the public side of CandleDojo around those goals.

Why I cared about SEO and GEO

At first, most of the discoverability was basically brand-driven.

That means if someone already knew CandleDojo or typed Candle Dojo, they could probably find it.

But that is not the real challenge.

The real challenge is showing up for the kind of searches people use when they do not know your product yet:

candlestick practice tool
chart reading trainer
how to practice price action
trading replay simulator
bar replay vs paper trading
best way to practice chart reading

That is the SEO side.

The GEO side is slightly different.

For me, GEO is not about stuffing “AI” everywhere.
It is about making the site easier for generative systems to classify, summarize, and recommend.

In other words:

what is this product?
who is it for?
what problem does it solve?
when should it be recommended instead of something else?

I wanted CandleDojo to answer those questions much more clearly.

What CandleDojo actually is

This was the first thing I had to fix.

I stopped assuming the branding alone was enough.

So instead of leaving the product too abstract, I started being much more explicit about the language on public pages.

CandleDojo is now described more clearly as:

a chart-reading trainer
a candlestick practice tool
a product for price action practice
a way to train with historical charts and structured reps

That sounds simple, but I think it matters a lot.

Search engines do better when the product category is clear.
LLMs also do better when the product can be placed into a clean mental bucket.

If the site only sounds clever or branded, it is harder to rank and harder to recommend.

If the site clearly says what it is, the odds get much better.

What I changed on the site

The biggest shift was structural.

I stopped treating public pages like isolated marketing pages and started treating them like a real content system.

I split the public surface into clearer sections:

/guides for educational and problem-aware content
/patterns for glossary-style candlestick pattern pages
/vs for comparison intent
/tools for interactive assessments
/insights for first-party research and reporting
/newsletter for owned audience growth

That gave each page type a more specific job.

For example:

a guide can target questions like “how to practice price action”
a comparison page can target high-intent searches like “CandleDojo vs TradingView Replay”
a tool page can capture people looking for a chart-reading assessment or candlestick quiz
an insight page can build trust and give the product something more citeable

That last point matters more than I expected.

A lot of GEO-friendly content is not just “content.”
It is content that is easy to quote, summarize, or reference.

What I changed specifically for GEO

For GEO, I tried to focus on clarity over gimmicks.

A few things seemed especially important:

1. Clear product classification

I made sure the pages say what CandleDojo is in plain English.

Not just “train your chart reading.”
More like:

CandleDojo is a chart-reading trainer
CandleDojo is a candlestick practice tool
CandleDojo helps traders practice reading price action on historical charts

That gives LLMs much better raw material.

2. Pages that match recommendation intent

A lot of AI questions are recommendation-shaped.

So I leaned into content that naturally answers those kinds of prompts:

best way to practice chart reading
what makes a good chart-reading trainer
bar replay vs paper trading
candlestick pattern practice tool
trading replay simulator

Those are not giant vanity keywords, but they are much closer to actual product discovery.

3. Better internal linking

I wanted the public content to feel like a connected graph instead of scattered pages.

So pattern pages can point to related tools or guides.
Guides can point to assessments.
Insight pages can point back into the product.
Comparison pages can link to deeper educational content.

That helps both users and machines understand how the topics connect.

4. Crawl accessibility for public pages

I also updated the crawl policy so public content can be accessed more broadly, while private app routes stay blocked.

That means pages like guides, tools, comparisons, and insights are part of the public surface, while routes like /play, /profile, /auth, and /api stay out of that layer.

For me, that is the right split:
make the public knowledge surface accessible, and keep the actual app internals private.

What I changed for measurement

One thing I really did not want was to spend weeks “doing SEO” and then only know whether pageviews went up.

That is not enough.

So I added more attribution and event tracking around the public funnel.

I started tracking things like:

page views
CTA clicks
tool starts
tool completions
newsletter signups
signup starts
signup completions

I also added first-touch attribution on signup.

That matters because I want to know which content types actually help create users.

Not just:

which page got traffic

but:

which page led to a newsletter signup
which page led to a tool completion
which page helped start an account signup

That feels much closer to the real job.

What I changed for scale

I also built a weekly content pack workflow around CandleDojo.

Instead of thinking about SEO posts, videos, newsletter content, and directory snippets as separate workflows, I wanted one source topic to create a full pack.

So one topic can produce:

one primary content asset
one YouTube script
a few short-form hooks
one newsletter block
one directory/profile snippet

This makes the system much more scalable.

It also fits how I think about search now.

The same core idea should be able to show up across:

Google Search
AI-generated recommendations
YouTube
newsletter
directory/referral traffic

Different channels, same underlying intent.

That feels much more durable than creating random one-off content.

What I learned

A few things became clearer while doing this.

Broad keywords are not the point

Trying to rank for something like candle, dojo, or even trading is not the right game.

The better targets are narrower and more product-shaped:

chart-reading trainer
candlestick practice tool
best way to practice chart reading
trading replay simulator
bar replay vs paper trading

Those are much more realistic and much more useful.

GEO is not magic

Just letting AI crawlers access your site does not automatically make your product recommendable.

If the pages are vague, thin, or hard to classify, LLMs still will not have much to work with.

The real work is still:

clarity
structure
useful page types
internal linking
recommendation-friendly language

Tools and comparisons are strong assets

I think interactive tools and comparison pages are underrated.

A generic blog post can be useful, but a good tool page or a strong comparison page often does a much better job of matching high-intent discovery.

The content system matters as much as the writing

The more I worked on this, the more it felt like an information architecture problem, not just a writing problem.

You are not only writing articles.
You are teaching search engines and LLMs how your product should be understood.

Where I am now

I do not think SEO or GEO is something you “finish.”

It feels more like building a long-lived public knowledge layer around the product.

For CandleDojo, that layer now has a much clearer shape:

educational guides
pattern pages
comparison pages
interactive tools
insight pages
newsletter capture
attribution so I can measure what actually works

It is still early, but this already feels much better than hoping the homepage alone will do all the work.

Final thought

My current takeaway is pretty simple:

if you want your product to show up in both search and AI recommendations, do not just publish more content.

Make your site easier to understand.

Make it obvious what the product is, who it is for, and when it should be recommended.

That has been the real shift for me with CandleDojo.

If you want to check it out, it’s here:

https://candledojo.app

I Built "Duolingo for Chart Reading" as a Solo Dev - Here's What I Learned

Joel — Thu, 26 Mar 2026 19:00:38 +0000

There are thousands of resources that teach you what a hammer candlestick looks like. Almost none of them make you actually practice spotting one in a real chart.

Reading price action is a visual skill. You can't learn it from flashcards. You learn it the same way you learn to read sheet music or spot patterns in an X-ray - through repetition with real data.

So I built CandleDojo. It gives you a real historical chart, you call the direction, and then the chart replays forward so you see what actually happened.

How it works

You see a frozen moment from a real BTC, ETH, or SOL chart
You read the candles and call bullish or bearish
The chart replays forward - instant feedback
A belt system (white to black) tracks your progression across 3,700+ scenarios

No sign-up required. You can start practicing immediately.

The stack

Layer	Tool
Framework	Next.js 15 (App Router)
Auth + DB	Supabase (Postgres + RPC)
Hosting	Vercel
Styling	TailwindCSS
Charts	Hand-rolled HTML Canvas

I didn't use a charting library. The replay animation needed frame-level control over candle rendering, so the entire chart component is built directly on the Canvas API.

What was actually hard

The scenarios, not the code. A random slice of price data is usually flat and boring. I had to build a generation pipeline that filters for interesting price action - clear trends, reversals at key levels, recognizable patterns - and tags each scenario by difficulty level.

Difficulty balance broke retention. The first version had 87% hard scenarios. New users went on losing streaks and bounced. After rebalancing to 14% easy, 18% medium, 67% hard, session lengths went up immediately.

Round saves had race conditions. A single round completion touches XP, belt unlocks, streaks, weekly challenges, and profile stats. The first implementation was 13+ sequential database calls and took 3-5 seconds. I collapsed it into one atomic Postgres RPC function. Save time dropped to under a second.

Lessons from building solo

Ship the core loop first. I built belts, weekly challenges, streak tracking, and an admin dashboard before anyone had used the app. The only thing that mattered early was: show chart, get input, replay result. Everything else could have waited.

Distribution is a separate problem from building. I had zero audience when I launched. The product could have been ready months earlier if I'd started building in public from day one.

Talk to users before you assume. I built difficulty balancing based on gut feel. Five minutes of watching someone use the app would have shown me the problem immediately.

What's next

I'm working on adding SPY and ES/NQ futures (the trading community asked for these), a badge system, and figuring out monetization. Right now it's completely free.

If you trade, or you're curious about how the chart rendering or scenario generation works, I'm happy to go deeper on any of it.

Try it here - no sign-up needed