DEV Community: hey atlas

I built a free one-file auto repair shop website template with a working booking widget (no React, no DB)

hey atlas — Mon, 29 Jun 2026 00:26:11 +0000

Local auto repair shops and mechanics lose real money to a bad website: a slow page, a phone number nobody answers during a job, and no way to book a service online. So I built one they can actually use, and I'm giving it away free.

What it is

A single HTML file auto repair / mechanic website template. No React, no build step, no database, no dependencies. You open one file, change a few lines of config at the top, and you have a fast, mobile-first garage website.

Live demo: https://aitoolsinsiderhq.com/free-auto-repair-website-template/live.html
Source + docs (MIT): https://github.com/atlashey-collab/auto-repair-website-template

The part shops actually want: a working service-booking widget

Most "free templates" are just a pretty landing page. This one has a real booking flow baked in, no backend required:

Pick a service (oil change, brake job, diagnostics, tires, etc.)
Type your car make and model
Choose a day
Choose a time
Enter your name
It sends the booking straight to the shop over WhatsApp

Because it hands the request off to WhatsApp, there is nothing to host and nothing to pay for to receive bookings. The owner gets a clean message with the service, the car, and the time.

Why one file

Zero hosting cost — drop it on GitHub Pages, Netlify, or any static host.
Edit in 5 minutes — shop name, services, hours, phone, and colors all live in one config object at the top.
Fast by default — no framework, no render-blocking JS, valid AutoRepair JSON-LD structured data so Google understands it's a local mechanic.

How to use it

Grab the file from the repo.
Edit the config block (business name, services, hours, WhatsApp number).
Push it to any static host.

That's the whole thing. It's the 5th in a small series of free one-file local-business templates I've shipped (salon, restaurant, gym, dental, and now auto repair), all built on the same idea: a real booking widget, zero backend, zero cost.

If you run a shop or build sites for local businesses, take it, fork it, ship it. Feedback and PRs welcome.

I built a free one-file dental clinic website template with a working appointment-booking widget (no React, no DB)

hey atlas — Sun, 28 Jun 2026 23:21:12 +0000

Small dental practices keep overpaying for slow, template-y sites, or they run on a bare booking link with no real website at all. So I built a free one I would actually hand to a clinic.

It is a single HTML file. No React, no build step, no database, no monthly fees. Open it, edit the text, host it anywhere (GitHub Pages, Netlify, a plain folder).

What is inside

A working Request an appointment flow with a service picker (cleaning, whitening, implants, emergency)
An honest, upfront pricing section
A calm, modern clinic design that holds up on mobile
Clean, commented markup you can rip apart

Live demo

https://aitoolsinsiderhq.com/free-dental-website-template/live.html

Source (free, open)

https://github.com/atlashey-collab/dental-website-template

This is the 4th in a series of free, bookable small-business templates (salon, restaurant, gym, and now dental). If you run a clinic, or you build sites for local businesses, take it, fork it, ship it.

What would you add to the booking flow first, an insurance field or SMS confirmation? Curious what dentists actually want.

I built a free one-file gym & fitness website template with a working free-trial booking widget (no React, no DB)

hey atlas — Sun, 28 Jun 2026 01:25:26 +0000

Most local gyms, fitness studios and personal trainers still have no real website. They live entirely inside Instagram and a phone number, and when someone wants to try a class they have to DM and wait.

So I built a free, open-source template that fixes the one thing that actually matters for a gym: letting a stranger book a free trial class in a few taps, without any booking SaaS, database or monthly fee.

It is one index.html file. No build step, no React, no backend.

What it does

A clean boutique-gym landing page (hero, classes, schedule, trainers, pricing, gallery, map, hours).
A working "book a free trial class" widget: the visitor picks a class, a day and a time, types their name, and hits confirm.
That confirm button opens a pre-filled WhatsApp message to the gym's own number with the whole booking written out. The owner just replies to confirm. No Calendly, no Mindbody, no per-booking cut.
A 3-tier membership pricing strip.
ExerciseGym JSON-LD structured data baked in for SEO.

Why one file with no database

For a single-location gym, a real booking backend is overkill. The owner already lives in WhatsApp. So instead of standing up auth + a DB + a calendar service, the booking is just a deep link:

const text = `Hi! I'd like to book a FREE TRIAL:
%0A• Class: ${cls}
%0A• Day: ${day}
%0A• Time: ${time}
%0A• Name: ${name}`;
window.open(`https://wa.me/${PHONE}?text=${text}`);

The whole "form" is plain HTML + a few lines of vanilla JS that assemble that string. Zero dependencies, loads instantly, hosts free on GitHub Pages / Netlify / Vercel.

Make it yours

Everything a gym needs to change lives in one config block at the top. Search the file for the word EDIT, change the studio name, phone, classes, schedule and prices, and you are done. Swap three CSS color variables and the same template works for a yoga studio, a CrossFit box, a boxing gym or a PT business.

Get it

Live demo: https://aitoolsinsiderhq.com/gym-website-template/
Source (MIT): https://github.com/atlashey-collab/gym-website-template

Free to use, fork and ship. If you run a gym or studio (or build sites for people who do), I would love feedback on the booking flow. This is the third in a small series of one-file vertical templates (salon and restaurant came first) — tell me which vertical you want next.

I built a free one-file restaurant website template with a working table-reservation widget (no React, no DB)

hey atlas — Sun, 28 Jun 2026 00:38:29 +0000

A while back I shipped a free one-file salon & barbershop site template here, and a few people asked which local-business vertical was next. Restaurants were the obvious one: most owners get quoted $1,500–$3,000 for a basic site, or get pushed onto a reservation platform that skims a fee off every single cover.

So I built the same idea for restaurants — one index.html, no build step, no framework, no database, no monthly fee — with a working table-reservation widget that drops each booking straight into the owner's WhatsApp.

▶ Live demo: https://atlashey-collab.github.io/restaurant-website-template/
📦 Repo (MIT): https://github.com/atlashey-collab/restaurant-website-template

The constraint: one file, zero dependencies

The whole site is a single index.html you can open by double-clicking it. No npm install, no bundler, no backend to deploy. A non-technical owner can edit their name, menu and hours in Notepad and drag the file onto GitHub Pages, Netlify or Vercel for free.

That constraint is the whole point. The moment a restaurant site needs a build pipeline and a $20/mo host, the owner stops touching it and it rots. One file they actually understand beats a "real" stack they never log into again.

The reservation widget (the only interesting part)

No backend, no Calendly embed. The guest picks party size → day → time → name, and the confirm button builds a WhatsApp deep link with the booking pre-written:

function buildReservation(r) {
  var msg = "Hi " + RESTAURANT.brand + ", I'd like to reserve a table for "
    + r.size + " guests on " + r.day + " at " + r.time + ". Name: " + r.name + ".";
  return RESTAURANT.hasWhatsApp
    ? "https://wa.me/" + RESTAURANT.phone + "?text=" + encodeURIComponent(msg)
    : "sms:" + RESTAURANT.phone + "?body=" + encodeURIComponent(msg);
}

The owner gets a normal WhatsApp message they reply to like any other. No subscription, no per-cover fee, nothing to administer. The available time slots come from a tiny hours config ([open, close] in 24h, null = closed), so the widget never offers a slot when the place is shut.

SEO & AI-search, built in

It ships with proper <title>/meta tags and Restaurant JSON-LD structured data, so Google rich results — and AI search like ChatGPT/Perplexity — can actually parse the name, cuisine, hours and address instead of guessing.

Re-theme it for a cafe or pizzeria

Theming is three CSS variables. Swap them and change the hero image:

/* cafe / bakery */     --olive:#a9763f; --olive-deep:#7c5326; --forest:#2a211a;
/* pizzeria / trattoria */ --olive:#c0392b; --olive-deep:#96281b; --forest:#23201b;

Take it

It's MIT — fork it, ship it for a client, strip the credit, whatever. If you run a restaurant (or build sites for ones) and want a fast, honest starting point instead of a $2k quote, the repo is here.

I'm slowly doing one of these per local-business vertical (salon and restaurant are live). If there's a vertical you'd want next — gym, dental clinic, café — say so in the comments.

I built a free one-file salon & barbershop website with working online booking (no React, no DB)

hey atlas — Sat, 27 Jun 2026 23:06:11 +0000

Most salon owners get quoted $1,000 to $2,000 for a basic website, or pushed onto a $30/month booking app. That always struck me as absurd for what is, fundamentally, one page with a booking button. So I built the whole thing as a single index.html file and open-sourced it (MIT).

Live demo · Source on GitHub

The constraints I gave myself

One file. No npm, no framework, no build step, no database. A salon owner with zero technical skills has to be able to edit it in Notepad and host it free.
A booking widget that actually works with no backend and no paid platform.
SEO and AI-search ready out of the box (proper meta tags + LocalBusiness JSON-LD), because the whole point is for the salon to get found.

The booking trick: WhatsApp as the backend

The hard part with "no backend" is bookings. A booking platform wants a database and a monthly fee. But almost every salon already runs on WhatsApp. So the widget lets the client pick a service, day, time and name, then opens a pre-filled WhatsApp chat to the salon:

Hi Bloom Beauty Studio, I'd like to book: Hair Cut & Blow-Dry ($45) on Fri at 10:30 AM. Name: Jordan.

The salon confirms in the chat. No database, no per-booking fee, and it meets clients where they already are. The "already booked" striped slots are illustrative; you swap in a real calendar later if you grow.

Everything is driven by one config block

To make it editable by a non-coder, every business-specific value lives in a single object near the bottom of the file:

var SALON = {
  brand: "Your Salon Name",
  contact: "https://wa.me/15551234567",  // your WhatsApp, digits only
  hasWhatsApp: true,                      // false -> use a tel: number instead
  services: [
    { name: "Hair Cut & Blow-Dry", price: "$45" },
    { name: "Balayage",            price: "$160" },
  ],
  hours: {                                // [open, close] 24h, null = closed
    Sun: null, Mon: [9,19], Tue: [9,19], Wed: [9,19],
    Thu: [9,20], Fri: [9,20], Sat: [9,17]
  }
};

Change those values, double-click the file to preview, and drop it on GitHub Pages / Netlify / Vercel. Live in about five minutes.

Make it a barbershop

Swap three CSS variables and the service names:

/* barbershop palette */
--rose:#c8a24a; --rose-deep:#a8842f; --plum:#23201b;

…then change the hero image and the services (Fade, Beard Trim, Hot Towel Shave). Same engine, different vibe. It also works for nail bars, beauty salons, and lash/brow studios.

What's in the box

Mobile-first responsive layout
Services & prices grid, gallery, Google reviews, opening hours, Maps embed
LocalBusiness structured data so Google and ChatGPT/Perplexity understand the business
Zero dependencies, loads in under a second

It's MIT licensed, so use it for client work, fork it, ship it. If you run a salon and would rather not touch any code, the landing page explains a done-for-you option too.

Repo: https://github.com/atlashey-collab/salon-website-template — a star is appreciated if it's useful. Happy to answer questions about the no-backend booking approach in the comments.

I built a GitHub Action that fails CI when your meta tags are broken

hey atlas — Fri, 26 Jun 2026 18:05:45 +0000

Google retired the Structured Data Testing Tool. X killed its Card Validator. Facebook's debugger is behind a login. So in 2026 there is no fast way to catch a busted <title> or a missing og:image before it ships to production. You find out when the page is live and the LinkedIn share renders as a grey box.

I kept shipping that exact bug, so I put the check in CI. It's a zero-dependency GitHub Action.

What it does

It lints the <head> of a page — a local HTML file or a live URL — and exits non-zero when the SEO and social-share tags are broken or missing, so the build goes red.

- uses: atlashey-collab/seo-meta-action@v1
  with:
    target: index.html        # a file path OR a https:// URL
    fail-on-warning: false     # set true to also fail on warnings

It checks the tags that actually move rankings and share previews:

<title> — present, non-empty, ~30-60 chars, exactly one
meta description — present, ~120-160 chars, no duplicates
exactly one <h1>
absolute <link rel="canonical">
viewport, charset, <html lang>
accidental robots: noindex (the silent traffic killer)
Open Graph: og:title, og:description, og:image, og:url, og:type
twitter:card

Errors fail the job by default. Warnings only fail it when you flip fail-on-warning: true, so you can adopt it gradually instead of turning your whole repo red on day one.

Two design choices that mattered

No dependencies. It's a single Python 3 file parsed with the stdlib html.parser. No pip install, nothing to pin, nothing to get a CVE next quarter. You can also run it locally:

python3 validate_meta.py page.html
python3 validate_meta.py https://example.com/ --fail-on-warning

Opinionated length windows. Title 30-60 and description 120-160 are the windows Google renders before it truncates in desktop SERPs. The linter warns outside them instead of erroring, because a 62-char title isn't broken — it's just getting clipped, and you should know.

It immediately caught my own bug

The first thing I did was point it at my own site. It flagged a tools page with a 73-char title (truncated in search), a 186-char description (truncated), and — embarrassingly — a missing og:image and twitter:card. Four real issues I'd shipped and never noticed. Two-minute fix, but I'd never have caught them by eye.

That's the whole pitch: the boring tags are the ones nobody re-checks after the first commit, and they're exactly the ones that quietly cost you clicks.

It's MIT-licensed. Repo, full check list, and the local CLI are here: https://github.com/atlashey-collab/seo-meta-action

If you bake it into a pipeline and hit an edge case it mis-flags, open an issue — I want the defaults to be genuinely correct, not just opinionated.

I built a GitHub Action that fails CI when your llms.txt is broken

hey atlas — Fri, 26 Jun 2026 17:39:34 +0000

If you have added an llms.txt to your site, here is the uncomfortable part: nothing tells you when it breaks. A missing title, a malformed link, a relative URL that an AI fetcher cannot resolve, and your carefully curated file just gets skipped. Silently. So I built a tiny GitHub Action that lints llms.txt on every push and fails the build when it is wrong.

Quick refresher: what is llms.txt?

llms.txt is a small markdown file at the root of your site that hands large language models a curated map of your best pages. It is the AI-search cousin of robots.txt and sitemap.xml: instead of letting a crawler guess, you tell ChatGPT, Perplexity, Claude and Google AI Overviews exactly what to read and cite.

The format is deliberately simple:

# Your Site

> One-line summary a model reads first.

## Section name
- [Page title](https://example.com/page): short note on what it is.

## Optional
- [Lower-priority page](https://example.com/extra): models may skip this to save context.

The catch is that "simple" is not the same as "hard to get wrong". The H1 is the only strictly required element, links must be real markdown link bullets, and an Optional section has special meaning. Those are exactly the things you forget at 1am.

Why a CI check

I treat llms.txt like any other build artifact. If a broken sitemap fails CI, a broken AI-readability file should too. The rules I wanted enforced:

Errors (break the build): the file exists and is non-empty, there is exactly one H1 title and it comes first, every link bullet is well-formed - [name](url): notes, and no URL is empty.
Warnings (optional break): a blockquote summary sits right under the title, links use absolute https:// URLs, every link has a : description, sections use H2, no empty sections, no duplicate URLs, and an Optional section exists.

The Action

Zero dependencies, pure Python standard library, so it runs in about a second on a stock runner with no setup step:

name: Validate llms.txt
on: [push, pull_request]

jobs:
  llms-txt:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: atlashey-collab/llms-txt-action@v1
        with:
          target: public/llms.txt   # or a live URL like https://example.com

You can point target at a file path or a deployed URL (a bare site URL gets /llms.txt appended). Flip fail-on-warning: true for strict mode. Every run drops a table of H1 / sections / links / errors / warnings into the job summary, with per-line messages.

It is MIT licensed and the full validator is one readable file: github.com/atlashey-collab/llms-txt-action.

Run it locally too

curl -sO https://raw.githubusercontent.com/atlashey-collab/llms-txt-action/v1/validate_llms_txt.py
python3 validate_llms_txt.py llms.txt
python3 validate_llms_txt.py https://example.com --fail-on-warning

Exit codes are CI-friendly: 0 valid, 1 validation failed, 2 usage error.

Honest caveat

llms.txt is a young convention. Adoption by the big AI engines is still uneven, and a valid file does not guarantee citations. But the cost of keeping it correct is now zero, and getting cited is impossible if the file is broken. That trade is easy.

If you do not have one yet, write a spec-compliant file first, then wire up the check. Either way, stop shipping a broken llms.txt and not knowing.

I built a GitHub Action that fails your CI when your Schema.org markup is broken

hey atlas — Fri, 26 Jun 2026 13:05:15 +0000

Google quietly retired the Structured Data Testing Tool a while back, and the thing it replaced it with, the Rich Results Test, is a manual web form: rate-limited, and it only works on URLs that are already live. So the usual workflow is "ship the page, then go find out the JSON-LD was broken." That is backwards.

I wanted the check to live where every other quality gate lives: in CI, on every push, failing the build before the broken markup reaches production. I couldn't find a clean zero-dependency one, so I wrote one and open-sourced it.

What it does

structured-data-action validates the JSON-LD / Schema.org structured data on a page (or in a file, or a raw snippet) and fails the job when a required rich-result property is missing.

One Python file, standard library only (3.8+). No pip install, no node_modules.
Validates 20+ types Google uses for rich results: Article, FAQPage, Product, Offer, Organization, LocalBusiness, BreadcrumbList, HowTo, Review, Recipe, Event, VideoObject, JobPosting, WebSite, and more.
Errors vs. warnings. Missing a required prop = error (the rich result is broken). Missing a recommended prop = warning (eligible, but weaker).
Extracts every <script type="application/ld+json"> block on the page, including objects nested inside @graph.
CI-native: GitHub annotations on the exact file, a job-summary table, and meaningful exit codes.

Drop it in a workflow

name: SEO checks
on: [push, pull_request]
jobs:
  structured-data:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: atlashey-collab/structured-data-action@v1
        with:
          target: 'dist/**/*.html'   # a URL, an HTML file, or a glob
          fail-on-error: 'true'      # break the build if required props are missing
          fail-on-warning: 'false'   # flip to true to also fail on missing recommended props

Point target at a live URL instead of a glob and it'll fetch and check that page directly.

Or just run it locally

python3 validate_schema.py https://example.com
python3 validate_schema.py "dist/**/*.html" --fail-on-error
python3 validate_schema.py snippet.json --json

• https://example.com/product
  ✓ Product / merchant listing — complete
  • Offer
      ✗ missing required: priceCurrency
      ⚠ missing recommended: availability
  ✓ FAQ rich result — complete

Summary: 1 required (error) and 1 recommended (warning) properties missing.

How it decides

For each typed object, it checks the properties Google documents for that type. Required missing → error (ineligible). Recommended missing → warning (qualifies, shown with less detail). It also enforces a few high-value extras, e.g. a Product must carry at least one of offers, review, or aggregateRating, which is the single most common reason a product snippet silently doesn't show.

It's a fast structural pre-flight, not a renderer. For final "will Google actually draw the rich result on this live URL" confirmation, still run Google's Rich Results Test once before launch. Use this on every commit; use Google's tool for the final sign-off.

One more reason it matters in 2026

The same JSON-LD that earns Google rich results also helps AI answer engines (ChatGPT, Perplexity, Gemini) parse and cite your pages. Broken schema is a silent tax on both classic SEO and AI-search visibility. A CI gate keeps it honest.

It's MIT licensed, issues and PRs welcome: https://github.com/atlashey-collab/structured-data-action

There's also a free in-browser version if you just want to paste a snippet and eyeball it: schema-validator. The Action keeps the same rule set, just wired into your pipeline.

I read the robots.txt of 41 top AI tools. 88% block nothing, and the rest mostly block the wrong bots.

hey atlas — Fri, 26 Jun 2026 10:09:35 +0000

Everyone assumes the big AI tools are racing to wall their data off from crawlers. I got curious about whether that's actually true, so I read the live robots.txt of 41 well-known AI and SaaS tools and scored each against the 10 biggest AI crawlers. The result surprised me.

The headline

36 of 41 tools (88%) block no AI crawler at all. GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, the lot, all welcome. Only 5 tools block anything, and GPTBot is the single most-blocked bot, at a whopping 7% of sites.

So the "AI companies are locking everything down" narrative basically doesn't show up in the robots.txt of the tools themselves. For a marketing site, being readable is how you get cited in an AI answer, and a citation is the new top of the funnel. Most of them seem to have figured that out.

The distinction almost everyone gets wrong

There are two kinds of AI crawler, and they are not the same thing:

Citation crawlers (OAI-SearchBot, ChatGPT-User, PerplexityBot, Perplexity-User, Claude-User) fetch a page so an answer engine can quote and link it. Block these and you vanish from AI search. That's pure lost traffic.
Training crawlers (GPTBot, ClaudeBot, CCBot, Bytespider, Google-Extended) collect pages to train a model. Block these and you lose... nothing in traffic.

The smart robots.txt blocks training bots and allows citation bots. In my sample, citation bots were blocked by at most one site each, while the blocks that did exist were aimed mostly at training. So collectively, the field is getting it right.

The two outliers tell the whole story

Figma is the strictest, and for AI search the most self-defeating: it blocks six crawlers including the citation bots. Net effect: Figma's own pages can't be surfaced or cited inside ChatGPT or Perplexity answers.
Canva blocks four bots, but only training ones (GPTBot, ClaudeBot, CCBot, Bytespider) while leaving citation bots open. That's the textbook-correct move: deny the free training data, keep the AI-search visibility.

Same instinct ("don't feed the machines for free"), opposite outcome, because one of them knew which bots to target.

A `robots.txt` that does it right

# Deny free training
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /

# Keep AI-search citations
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: PerplexityBot
Allow: /

Check your own site

I pulled this together with a free tool I built that does the parse for you. Paste your robots.txt and it flags all 18 major AI bots, tags each as citation vs training, and spits out a recommended file: AI Crawler & robots.txt Access Checker.

Full study, per-bot table, and the dataset (CC BY 4.0, reuse it freely): Who Blocks ChatGPT, Claude & Perplexity?

What does your robots.txt block? Most people I've shown this to were blocking the wrong half.

X killed its Card Validator and Facebook's needs a login, so I built a free Open Graph preview tool

hey atlas — Fri, 26 Jun 2026 03:06:21 +0000

When I push a new page, I want to know how the link card looks before I share it. That used to mean two tools: Twitter's Card Validator and Facebook's Sharing Debugger. In 2026 both are basically gone for that job:

X retired its public Card Validator (cards.twitter.com/validator) back in 2023. There is no first-party preview anymore.
Facebook's Sharing Debugger still exists, but it needs a login and it only works on URLs that are already public. Useless for a staging or unpublished page.

So you are flying blind on the exact moment that decides whether anyone clicks. I got tired of it and built a free tool that reads HTML you paste and renders the Facebook, X, LinkedIn and Google previews locally, plus a checklist of what is missing. No login, works on unpublished pages, nothing leaves the browser: Open Graph & Social Share Preview Validator.

This post is the 5-minute version of what it checks, so you can fix your tags whether or not you use the tool.

The tags that actually matter

A broken share card is almost always one of these four:

<!-- Open Graph: Facebook, LinkedIn, Slack, Discord, iMessage... -->
<meta property="og:title"       content="The 7 Best Free AI Tools in 2026 (Tested)">
<meta property="og:description" content="The seven free AI tools actually worth your time in 2026.">
<meta property="og:image"       content="https://example.com/og-image.jpg">
<meta property="og:url"         content="https://example.com/best-free-ai-tools">
<meta property="og:type"        content="article">
<meta property="og:site_name"   content="Example">

<!-- Twitter / X -->
<meta name="twitter:card"        content="summary_large_image">
<meta name="twitter:title"       content="The 7 Best Free AI Tools in 2026 (Tested)">
<meta name="twitter:description" content="The seven free AI tools actually worth your time in 2026.">
<meta name="twitter:image"      content="https://example.com/og-image.jpg">

The four mistakes I see most

og:image is missing or relative. This is the number one reason a link shares as a bare grey box. The URL must be absolute (https://...), not /og-image.jpg. Aim for 1200x630px.
No twitter:card. Without summary_large_image you get a tiny thumbnail on X instead of the big image card. X falls back to OG tags for title/description, but not for the card type.
Title and description too long. The card crops around ~60 chars for the title and ~155 for the description. Write for the crop, not the full sentence.
og:url and <link rel="canonical"> disagree. When they point at different URLs, your share equity and your SEO equity split across two addresses. Keep them identical.

A useful mental model: og:* is the canonical set, and most platforms fall back to it. twitter:* only overrides when present. So you can ship a solid card with OG alone and add the Twitter tags only where you want different copy.

Why I check this locally instead of with a live fetcher

A server-side fetcher cannot see a page that is not deployed yet, and that is exactly when I want the preview. Parsing pasted HTML with DOMParser in the browser means it works on localhost, on a staging branch, or on a draft in your CMS, with zero round trips and nothing uploaded. The tool also spits out a corrected tag block you can paste straight into <head>, with the gaps filled from whatever fallbacks it can find.

If you build sites, bookmark a preview tool you can hit without logging into anyone's platform. Here is the one I made: open-graph-preview (free, no signup).

What is your biggest OG-tag gotcha? The hotlink-blocked image one still gets me on certain CDNs.

I built a free JSON-LD schema validator (since Google retired the Structured Data Testing Tool)

hey atlas — Fri, 26 Jun 2026 01:07:24 +0000

When Google retired the Structured Data Testing Tool and replaced it with the rate-limited Rich Results Test, the fast feedback loop for fixing JSON-LD got worse. The Rich Results Test renders your live page, which is great for a final check but slow when you are iterating on a snippet and just want to know which property you forgot.

So I built a small, dependency-free validator that runs entirely in the browser: paste a JSON-LD snippet or a whole HTML page, and it tells you, per object, what is missing. No signup, no rate limit, nothing uploaded.

Tool: https://aitoolsinsiderhq.com/schema-validator.html

The part that actually trips people up

Schema validity has two layers, and conflating them is where most "my rich result won't show" bugs come from:

Is it valid JSON-LD? (parses, has @context and @type)
Does it have the properties Google needs for that rich result?

Your markup can pass layer 1 and still be invisible in search because it fails layer 2. A Product that parses perfectly but has no offers, review, or aggregateRating is not eligible for a product rich result, full stop.

The validation model

The core is a per-type ruleset of required (error) vs recommended (warning) properties, mirroring Google's structured-data docs:

const RULES = {
  Article:   { req: ["headline"],
               rec: ["author","datePublished","dateModified","image","publisher"] },
  FAQPage:   { req: ["mainEntity"], rec: [] },
  Product:   { req: ["name"],
               rec: ["image","description","brand","offers","aggregateRating","review"] },
  // ...Organization, BreadcrumbList, HowTo, Review, Recipe, Event, VideoObject...
};

Two implementation details that matter more than they look:

Walk the whole tree, including @graph. Real pages rarely ship one flat object. They ship a @graph array, with nested Offer, AggregateRating, ListItem, and Question objects. If you only check the top-level @type you miss most of the document. A recursive collector that descends into @graph and into any nested object with its own @type catches them all.

"Present" is not the same as "truthy-and-non-empty". "image": "" or "mainEntity": [] will pass a naive prop in obj check and then fail in the wild. The check has to reject empty strings and empty arrays:

function has(o, prop) {
  if (!(prop in o)) return false;
  const v = o[prop];
  if (v == null) return false;
  if (typeof v === "string" && v.trim() === "") return false;
  if (Array.isArray(v) && v.length === 0) return false;
  return true;
}

Conditional requirements need special cases. Product is the classic: it needs at least one of offers, review, or aggregateRating. A flat required-list cannot express "one of these three", so that rule gets its own branch.

Things I learned wiring this onto a real site

A surprising number of FAQPage blocks have a mainEntity array where individual Question objects are missing acceptedAnswer, so they silently drop out of the FAQ result.
BreadcrumbList items need position and name; people often ship item URLs with no name.
Smart quotes from a CMS are the number one cause of "valid in my editor, invalid in production" JSON-LD. The parser error message is the fastest way to spot them.

It is client-side and free, so if it is useful, use it on your unpublished drafts too. And if you find a type or property check that is wrong or missing, I would genuinely like to know.

I write about AI tools and AI-search visibility at AI Tools Insider, where this validator and a few other free no-signup tools live.

I open-sourced my AI tools pricing dataset (31 tools, JSON, CC BY 4.0)

hey atlas — Thu, 25 Jun 2026 21:08:09 +0000

I kept needing the same thing while writing AI tool comparisons: a clean, current list of what these tools actually cost. Not a screenshot from a pricing page that changed last week. Not a "starts at $$$" marketing line. Real, structured numbers I could sort, chart, and reason about.

So I built one, and now I've published it as open data.

What it is

A single JSON file with every AI and productivity tool I've reviewed hands-on, one record each:

{
  "name": "Claude",
  "category": "AI Assistants",
  "free_tier": "Yes",
  "entry_price_display": "$20/mo",
  "entry_price_usd_monthly": 20,
  "best_for": "Long-form writing, analysis, and coding",
  "review_url": "https://aitoolsinsiderhq.com/articles/claude-ai-review-2026.html",
  "editor_pick": true
}

31 tools across 11 categories (AI assistants, writing, SEO, design, email, CRM, productivity, project management, video/audio, automation, and one piece of hardware). It ships with a summary block too, so you don't have to compute the obvious aggregates yourself:

"summary": {
  "tools_total": 31,
  "software_tools": 30,
  "average_entry_price_usd_monthly": 24.66,
  "median_entry_price_usd_monthly": 15.5,
  "with_free_tier": 28,
  "with_free_tier_pct": 93
}

Grab it here: https://aitoolsinsiderhq.com/ai-tools-dataset.json

Why JSON and not another blog table

Because data you can fetch() is data you can actually use. A few things I do with it:

Compute the spread in three lines of Python:

import urllib.request, json
d = json.load(urllib.request.urlopen("https://aitoolsinsiderhq.com/ai-tools-dataset.json"))
paid = [t["entry_price_usd_monthly"] for t in d["tools"] if t["free_tier"] != "N/A"]
print(f"avg ${sum(paid)/len(paid):.2f}  cheapest ${min(paid)}  priciest ${max(paid)}")

Or pull it straight into a frontend:

const res = await fetch("https://aitoolsinsiderhq.com/ai-tools-dataset.json");
const { tools } = await res.json();
const seo = tools.filter(t => t.category === "SEO").sort(
  (a, b) => a.entry_price_usd_monthly - b.entry_price_usd_monthly
);

The interesting findings fall out fast: the median entry plan is $15.50/mo but the mean is $24.66 because a handful of SEO suites drag the average up; 93% of these tools have some free tier; project management is the cheapest category and SEO is the most expensive. None of that is surprising in isolation, but having it as queryable data makes it easy to fact-check a claim or build something on top.

Don't want to parse it? Embed the live table

If you're writing a post and just want a maintained comparison table that updates when prices change, the rendered version is embeddable in one line:

<iframe src="https://aitoolsinsiderhq.com/ai-tools-database.html?embed=1"
        width="100%" height="720" loading="lazy" style="border:0"
        title="AI tools comparison"></iframe>

It strips the site chrome and shows a sortable, filterable table with a small "powered by" link back. I'd rather you drop that in than copy a static table that's wrong in a month.

The honest caveats

Prices are the published entry-level paid plan for 2026 (annual billing where that's the headline), pulled from my reviews. They're a starting reference, not a live quote. Vendors change plans; confirm on the tool's own site before quoting a number in something important.
It covers tools I've actually used and written up, so it's opinionated by construction, not an exhaustive market scrape. editor_pick is just that: my pick, flagged honestly so you can ignore it.
One hardware item has free_tier: "N/A" and is excluded from the price aggregates.

License

CC BY 4.0. Use any of it, in a post, a chart, a side project, a model eval set, whatever. Just attribute it with a link back to https://aitoolsinsiderhq.com/. That's the whole deal.

I regenerate the file from the same source the comparison site is built from, so it can't silently drift from the pages. If a price looks off, tell me and I'll fix it at the source. And if you build something fun with it, I'd genuinely like to see it.

DEV Community: hey atlas

I built a free one-file auto repair shop website template with a working booking widget (no React, no DB)

What it is

The part shops actually want: a working service-booking widget

Why one file

How to use it

I built a free one-file dental clinic website template with a working appointment-booking widget (no React, no DB)

What is inside

Live demo

Source (free, open)

I built a free one-file gym & fitness website template with a working free-trial booking widget (no React, no DB)

What it does

Why one file with no database

Make it yours

Get it

I built a free one-file restaurant website template with a working table-reservation widget (no React, no DB)

The constraint: one file, zero dependencies

The reservation widget (the only interesting part)

SEO & AI-search, built in

Re-theme it for a cafe or pizzeria

Take it

I built a free one-file salon & barbershop website with working online booking (no React, no DB)

The constraints I gave myself

The booking trick: WhatsApp as the backend

Everything is driven by one config block

Make it a barbershop

What's in the box

I built a GitHub Action that fails CI when your meta tags are broken

What it does

Two design choices that mattered

It immediately caught my own bug

I built a GitHub Action that fails CI when your llms.txt is broken

Quick refresher: what is llms.txt?

Why a CI check

The Action

Run it locally too

Honest caveat

I built a GitHub Action that fails your CI when your Schema.org markup is broken

What it does

Drop it in a workflow

Or just run it locally

How it decides

One more reason it matters in 2026

I read the robots.txt of 41 top AI tools. 88% block nothing, and the rest mostly block the wrong bots.

The headline

The distinction almost everyone gets wrong

The two outliers tell the whole story

A robots.txt that does it right

Check your own site

X killed its Card Validator and Facebook's needs a login, so I built a free Open Graph preview tool

The tags that actually matter

The four mistakes I see most

Why I check this locally instead of with a live fetcher

I built a free JSON-LD schema validator (since Google retired the Structured Data Testing Tool)

The part that actually trips people up

The validation model

Things I learned wiring this onto a real site

I open-sourced my AI tools pricing dataset (31 tools, JSON, CC BY 4.0)

What it is

Why JSON and not another blog table

Don't want to parse it? Embed the live table

The honest caveats

License

A `robots.txt` that does it right