Forem: Dennis Morello

Configuring My Site for AI Discoverability

Dennis Morello — Tue, 21 Apr 2026 08:02:58 +0000

A growing share of web traffic doesn't come from people anymore. It comes from models reading on their behalf. ChatGPT, Claude, Perplexity, Copilot. They fetch a handful of pages, summarize, and ship the answer back. If your site isn't readable by those agents, you don't exist to them.

People are calling this GEO, short for Generative Engine Optimization. It overlaps with SEO but the priorities are different. Agents don't care about your layout. They care about your prose, your metadata, and how many tokens it costs them to read you.

This post covers how I configured this site for GEO. The first half is framework-agnostic. The second half is specific to my setup on Cloudflare, and includes a deliberate choice that fails a popular GEO audit. I'll explain why.

Part 1: general GEO techniques

Serve raw Markdown alongside HTML

The single biggest GEO win is giving agents a version of each page without the navigation, styling, and scripts. HTML is designed for browsers. Markdown is designed for readers, human or otherwise. Agents spend their context window on your prose, not your DOM.

Every blog post on this site has a mirror URL with a .md suffix:

/blog/my-post is the full HTML page for humans
/blog/my-post.md is the raw Markdown, served as text/markdown

In Astro, this is a two-line route at src/pages/blog/[slug].md.ts:

export const GET = async ({ params }) => {
  const post = await getPostById(params.slug);
  return new Response(formatPostMarkdown(post), {
    headers: { "Content-Type": "text/markdown; charset=utf-8" },
  });
};

Both variants are pre-generated at build time. Same content, roughly half the tokens for an agent to consume.

Advertise the Markdown version in `<head>`

Agents landing on the HTML need to know the Markdown exists. A single <link> in the head does it:

<link rel="alternate" type="text/markdown" href="/blog/my-post.md" />

Browsers ignore this tag. Agents that parse the head follow it.

Publish an `llms.txt` index

llms.txt is a convention for a Markdown file at the root of your site listing your content with short descriptions and links. Think of it as a sitemap an LLM can actually read.

I ship two variants:

/llms.txt is the index. Title, description, one line per post with a link to its .md version.
/llms-full.txt is the full corpus. Every post body concatenated into a single response.

Why both? An agent researching a specific topic can fetch llms.txt, pick the relevant links, and pull them. An agent doing deep research on the site as a whole fetches llms-full.txt once and has everything it needs in one request. Either way there's no crawling.

Declare your AI stance in `robots.txt`

robots.txt now carries a Content-Signal directive for AI use. Mine reads:

User-agent: *
Content-Signal: search=yes, ai-train=no, ai-input=yes
Allow: /
Sitemap: https://morello.dev/sitemap-index.xml

Three independent knobs:

search=yes lets search engines index
ai-train=no says my content is not for training data
ai-input=yes says my content can be retrieved and used as input for AI answers

This is the stance I'm comfortable with. I want to show up when someone asks Claude about something I've written; I just don't want my posts absorbed into the next base model.

Whether any given operator actually honors this is another question. The signal's there regardless, and I'd rather be on record than silent about it.

Add structured data that actually describes the content

Most blogs ship JSON-LD schema by reflex. Few of them include the fields that help a generative engine decide whether your article is worth fetching.

On each post I emit a BlogPosting graph with:

wordCount and timeRequired (ISO 8601 duration), so an agent can estimate how much context it'll spend before fetching
articleBody, the full text machine-readable, with no HTML parsing required
author linked to a Person node with knowsAbout so the entity is grounded in real topics
BreadcrumbList for site hierarchy

All of it goes into a single @graph per page rather than scattered <script> tags, which makes it cheaper for an engine to walk from post to author to site without cross-referencing.

A sitemap that actually tracks freshness

If you regenerate your sitemap once and never look at it again, you're wasting a signal. Every URL in mine carries a lastmod timestamp pulled from the post's updatedDate frontmatter, falling back to pubDate. When I edit an old post, its lastmod moves forward and crawlers reprioritize it.

Validate with real tools

Two tools I found useful while iterating on all of the above:

isitagentready.com audits across five categories: discoverability, content accessibility, bot access control, protocol discovery, and commerce. The bot access control checks (Content-Signal, Web Bot Auth, AI bot rules) are the part that actually influences how agents treat your content.
acceptmarkdown.com has a narrower focus. It checks whether your site responds to Accept: text/markdown with a Markdown body, includes Vary: Accept, returns 406 for unsupported types, and parses q-values correctly.

I'll come back to the second one at the end of the post, because my site deliberately fails it.

Part 2: the Cloudflare-specific setup

General GEO gets you most of the way there. The rest is delivery. How fast you respond, whether the edge caches correctly, and how you advertise your agent-facing resources without waiting for someone to parse your HTML.

Static assets, zero Worker invocations

My wrangler.jsonc points a ./dist directory at Cloudflare's assets deployment, with no main entry:

{
  "name": "morellodev",
  "compatibility_date": "2026-04-18",
  "assets": {
    "directory": "./dist",
    "html_handling": "drop-trailing-slash",
    "not_found_handling": "404-page",
  },
}

Every request goes straight from the edge asset cache. HTML, Markdown, llms.txt, sitemap, RSS. Same path for all of them, and no Worker ever runs. On the Workers Free tier this matters. A crawler sweep that would otherwise eat into 100k daily invocations now costs me nothing. Agents, for better or worse, don't fingerprint politely.

Advertise discovery endpoints in a `Link` header

Cloudflare's _headers file lets you ship response headers without any server code. I use it to tell every response, not just HTML ones, where the agent-facing files live:

/*
  Link: </sitemap-index.xml>; rel="sitemap",
        </rss.xml>; rel="alternate"; type="application/rss+xml"; title="RSS",
        </llms.txt>; rel="describedby"; type="text/plain",
        </llms-full.txt>; rel="describedby"; type="text/plain"

A crawler doing a HEAD against any URL on the site sees all four links before it parses a single byte of HTML. One round-trip, no body, full discovery.

Long-lived cache for hashed assets

Astro emits fingerprinted filenames under /_astro/, so those can sit in cache for a year:

/_astro/*
  Cache-Control: public, max-age=31536000, immutable

Faster first paint for humans, cheaper crawls for agents. Same lever.

Why I skipped `Accept: text/markdown` content negotiation

acceptmarkdown.com will tell you this site doesn't do content negotiation. No Vary: Accept, no 406, no Markdown from the canonical URL. That's not an oversight. I tried it, shipped it briefly, and rolled it back.

The reason is Cloudflare's free plan. Custom cache keys are Enterprise-only, and their docs are explicit that Vary: Accept is ignored for caching decisions. The edge collapses every variant of /blog/my-post into one cache entry, so the first requester's format poisons the cache for everyone else until TTL expires.

The workaround is a Worker that bypasses the edge cache. But now every /blog/* request burns a Worker invocation, humans included, and the Workers Free plan gives you 100k per day and 10ms of CPU each. That's a real budget to share across humans and bots, for no functional gain over a static .md URL.

So I deleted the Worker. The only thing I lost is curl -H "Accept: text/markdown" …/blog/my-post returning Markdown. Between llms.txt, <link rel="alternate">, and the /blog/[slug].md convention, no mainstream agent I've seen actually needs Accept: negotiation. It's the more elegant protocol; alternate URLs are the more robust one on a free-tier CDN. On a paid plan I'd probably do both.

Where this leaves things

Every page exists in two forms, both served from the edge. Agent-facing resources are advertised in response headers on every request, before any HTML gets parsed. Structured data tells engines what the article is and how much context it takes to read. robots.txt says what I'll allow and what I won't.

GEO is still very new. The standards are half-drafted, the tools disagree with each other, and half the signals I described above didn't exist two years ago. I fully expect to be rewriting parts of this post within six months, probably with a different opinion about Accept-based negotiation, once I've either moved off the free plan or found a workaround that doesn't involve a Worker. But for now: serve agents a version they can cheaply consume, be explicit about what you'll allow, and accept that the defaults aren't on your side.

If you're reading this via a summary from some assistant, hi. Thanks for the traffic.

Git Worktrees Are Underrated

Dennis Morello — Mon, 16 Mar 2026 22:07:48 +0000

If you've ever stashed half-finished work to review a PR, or lost a train of thought switching branches, you should know about git worktrees. They've been in git since 2015, but most developers I talk to have never heard of them.

The problem with branches

The standard git workflow is linear. You're on a branch, you need to context-switch, so you stash your changes (or worse, make a throwaway commit), switch branches, do your thing, switch back, and pop the stash. If you're lucky, nothing conflicts.

This gets worse when you're juggling multiple things at once. Reviewing a colleague's PR while your feature branch is mid-refactor. Running tests on one branch while coding on another. Hotfixing production while your main work sits frozen.

A git repository has one working directory. One branch checked out at a time. Everything else has to wait.

Worktrees

Git worktrees let you check out multiple branches simultaneously, each in its own directory. They share the same .git history and objects, so you're not cloning the entire repo, but each one has its own working directory and index.

git worktree add ../feat-login feat/login

Now feat/login is checked out in ../feat-login. You can open it in a separate editor window, run tests there, or just let it sit while you work on something else.

When you're done:

git worktree remove ../feat-login

Why nobody uses them

If worktrees are so useful, why aren't they more popular? I think it comes down to two things.

First, the directory problem. Every time you create a worktree, you have to pick a path. There's no convention for where they go. After a week you end up with directories scattered across your filesystem: ../feat-login, ~/tmp/hotfix-auth, ../../pr-review. Good luck remembering where anything is.

Second, there are no ergonomics. You can't easily list your worktrees with status info, cd into one quickly, or run something like npm install in the new directory after checkout. The raw git commands work, but they don't make worktrees feel like a real workflow.

These aren't fundamental problems with worktrees. They're tooling gaps. That's why I built arbor.

A better workflow with arbor

Arbor is a CLI that manages git worktrees. It keeps them organized in a central directory (~/.arbor/worktrees/) and handles the stuff that plain git doesn't.

# Clone a repo (sets up a bare repo + default branch worktree)
arbor clone user/my-app

# Create a worktree for a new feature
arbor add feat/login

# Shell integration auto-cds you into the worktree
# You're now in ~/.arbor/worktrees/my-app/feat-login

# Need to review a PR? Open another worktree
arbor add fix/auth-bug

# See all your worktrees with dirty/clean status
arbor status

Every worktree for my-app lives under ~/.arbor/worktrees/my-app/. Branch slashes become dashes in directory names, so the filesystem stays tidy. When you're done with a branch:

arbor rm -d feat/login

That removes the worktree and the local branch in one step.

What makes it stick

I've been using worktrees for a while, but I kept falling off because of the friction. A few things in arbor made the difference for me.

Shell integration. arbor init sets up a wrapper so that arbor add and arbor switch automatically cd you into the worktree directory. Without it you create the worktree and then have to cd into it yourself every single time, which gets old fast.

Post-create hooks. You can add an .arbor.toml to your repo:

[hooks]
post_create = "npm install"

Every new worktree gets its dependencies installed automatically. You can chain commands too:

[hooks]
post_create = ["npm install", "cp .env.example .env"]

And arbor status --all shows the state of every worktree across all your repos, which is nice for a quick scan before you call it a day.

Where I use them most

PR reviews. arbor add the branch, review it in a separate editor window, remove it when done. My own work is untouched.

Long test suites. Tests running on one branch, coding on another. No waiting around.

Hotfixes. arbor add hotfix/critical, fix it, push it, remove it. Back to what I was doing.

Comparing behavior. Two worktrees open side by side, one on main and one on my feature branch. Way easier than switching back and forth.

Big migrations. Upgrading a framework to a new major version in a worktree while the rest of the team keeps shipping from main. No half-broken build blocking anyone.

Try it

Arbor is open source, written in Rust. Install with Homebrew:

brew install morellodev/tap/arbor

Or grab a binary from the releases page.

Run arbor init after installing to set up shell integration. Takes about 30 seconds.

If you've never tried worktrees, give them a shot. And if you have but gave up because of the directory mess, this might be worth another look.

morellodev / arbor

A friendly CLI for managing git worktrees

🌳 arbor

A CLI for managing git worktrees. It keeps all your worktrees under ~/.arbor/worktrees so you can switch between branches without stashing or losing context.

Why arbor?

Git worktrees are great: multiple branches checked out at once, no stashing, no half-finished commits. The problem is that git worktree add makes you pick a directory every time, and you end up with worktrees scattered everywhere.

Arbor puts them all in one place. arbor add feat/login creates the worktree, and with shell integration it cds you into it too. arbor rm feat/login cleans it up.

Who is this for?

If you review PRs while working on your own feature, juggle hotfixes alongside long-running branches, or run tests in one worktree while coding in another — arbor keeps everything organized.

Install

Homebrew (macOS and Linux)

brew install morellodev/tap/arbor

Pre-built binaries (macOS, Linux, Windows)

Download the latest binary for your platform from…

View on GitHub

Recreating History: Building a Windows 98 Disk Defrag Simulator with Modern Web Tech

Dennis Morello — Sun, 14 Jul 2024 09:41:54 +0000

Hey fellow devs! I'm Dennis Morello, a Senior Frontend Engineer with a passion for both cutting-edge web technologies and retro computing. I'm excited to share my latest project that combines these interests: a faithful recreation of the Windows 98 Disk Defragmenter, built entirely for the web.

Check it out: defrag98.com

Update 19 Jul 2024: We're on Product Hunt! 🚀

Great news, everyone! The Windows 98 Disk Defragmenter Simulator is now live on Product Hunt. This is an exciting milestone for the project, and I'm thrilled to share it with a wider audience of tech enthusiasts and nostalgia lovers.

Update 14 Jul 2024: Featured on The Verge and Hacker News!

The project has been featured on Hacker News and The Verge! Thank you to everyone who has tried it out and shared their love for this blast from the past.

The Tech Stack

For this project, I leveraged some of the most powerful tools in modern web development:

React: For building the UI components
Next.js: To optimize performance and SEO
Zustand: To manage the state of the app
TailwindCSS: To style the app, along with 98.css for bringing in the Windows 98 aesthetic
Radix UI Primitives: For accessible interactive components like sliders and modals
Vercel: The hosting platform for the app

Challenges and Solutions

1. Recreating the Defragmentation Algorithm

One of the biggest challenges was implementing a defragmentation algorithm that felt authentic. I created a custom algorithm that:

Randomly selects clusters to process
Simulates file movements across the disk
Adjusts processing speed based on the selected virtual drive

2. Pixel-Perfect UI Recreation

Achieving the exact look and feel of Windows 98 required meticulous attention to detail. I used a combination of 98.css and TailwindCSS to:

Match colors precisely
Recreate the characteristic 'chunky' borders
Implement the classic Windows 98 typography

3. Simulating Hard Drive Sounds

To add an extra layer of nostalgia, I implemented realistic hard drive sounds. This involved:

Recording and editing authentic HDD sounds
Leveraging the Web Audio API for precise playback control
Synchronizing sound effects with the visual defragmentation process
Adapting the HDD sounds to the chosen drive speed

What I Learned

This project was a fantastic opportunity to:

Deep dive into the intricacies of writing a custom defrag algorithm, and find a balance between performance and simulation accuracy
Explore the challenges of accurately simulating legacy software
Push the boundaries of what's possible in browser-based applications

What's Next?

This is a project I started just for fun, but I'm excited to see where it goes. I'm looking forward to continuing to improve the app, and adding more features as feedbacks from users come in.

I'd love to hear your thoughts, suggestions, or questions about this project. Have you worked on similar retro tech simulations? What challenges did you face?

5 Things You Might Not Know About JavaScript

Dennis Morello — Thu, 08 Jun 2023 06:50:30 +0000

JavaScript is a programming language that has been around for over 20 years. It's used in many different ways, but what are some things you might not know about it? In this blog post, we'll explore 5 things you might not know about JavaScript.

Original post at https://morello.dev/articles/five-things-you-might-not-know-about-javascript

Introduction

JavaScript has undoubtedly become one of the most essential programming languages in the world of web development. As the backbone of interactive web pages, it enables developers to create dynamic and engaging user experiences. You might already be familiar with the basics of JavaScript, but there are numerous lesser-known aspects and hidden gems within the language that can enhance your coding skills and expand your understanding.

In this blog post, we'll delve into 5 intriguing things about JavaScript that you might not be aware of. Whether you're ready to impress your colleagues with newfound JavaScript knowledge or simply eager to enhance your own programming prowess, this blog post is for you. Let's dive in and uncover the hidden gems that await us in the vast world of JavaScript!

1 - "JavaScript" is trademarked by Oracle

The name "JavaScript" is a trademark of Oracle Corporation in the United States. The trademark was originally owned by Netscape Communications Corporation, which created the language in 1995. In 1996, Netscape transferred the trademark to Sun Microsystems, which was acquired by Oracle in 2010.

A trademark is a legal protection that grants exclusive rights to use a particular word, phrase, symbol, or design to identify and distinguish a product or service.

As a trademark holder, Oracle has the authority to control the usage of the term "JavaScript" within the United States. This means that other entities must seek permission from Oracle or adhere to specific guidelines if they wish to use the term in a way that may be covered by the trademark. Unauthorized use of a trademarked term can lead to legal repercussions.

It is important to note that while the term "JavaScript" is trademarked by Oracle in the United States, the programming language itself is an open standard governed by the ECMAScript specification. This means that the language can still be used and implemented by developers and organizations globally, regardless of the trademark ownership.

In 2022, Node.js and Deno creator Ryan Dahl wrote an open letter titled Dear Oracle, Please Release the JavaScript Trademark, where he urges Oracle to release JavaScript trademark.

2 - JavaScript and ECMAScript are not the same thing

JavaScript is often referred to as ECMAScript, but the two terms are not interchangeable. JavaScript is a programming language, while ECMAScript is a standardized specification that defines the syntax, semantics, and features of the JavaScript language. It provides a standardized framework for implementing JavaScript across different platforms and browsers.

ECMAScript is maintained by Ecma International, an industry association, and undergoes regular updates to introduce new features and enhancements.

It is important to note that different versions of JavaScript correspond to different editions of the ECMAScript specification. For example, ECMAScript 5 (ES5) introduced significant improvements and features to the JavaScript language, while ECMAScript 6 (ES6) brought about even more significant changes, such as arrow functions, classes, and modules.

In summary, JavaScript is the widely used programming language that follows the ECMAScript specification. ECMAScript provides the standardization and guidelines for implementing JavaScript across platforms, ensuring compatibility and allowing developers to write code that can be executed consistently.

3 - JavaScript is a dynamically typed language

As in every programming language, in JavaScript variables and values have types associated with them. Although JavaScript is often referred to as a dynamically typed language, meaning that variables can hold values of any type, it does have a type system that determines how values can be used and manipulated.

JavaScript employs a loose type system, where type coercion can occur implicitly, allowing for flexibility in operations between different types. For example, the + operator can be used to add numbers or concatenate strings, but also to cast a value to a number.

There is also an operator called typeof that can be used to determine the type of a value at a given point in time. It returns a string representing the type of the operand.

4 - JavaScript has seven primitive types

As of ECMAScript 2020 release, JavaScript has seven primitive types, which are the building blocks of all JavaScript values:

Boolean: Represents a logical value of either true or false.
Null: Represents the intentional absence of any object value. It is a primitive type, but its sole value is null.
Undefined: Represents a variable that has been declared but has not been assigned a value. If a variable is declared but not assigned a value, it is automatically assigned the value of undefined.
Number: Represents numeric values, including integers and floating-point numbers. JavaScript uses the double-precision 64-bit binary format (IEEE 754) to represent numbers.
BigInt: Introduced in ECMAScript 2020, BigInt is a primitive type that provides a way to represent arbitrarily large integers. It allows developers to perform operations on numbers beyond the limits of the Number type.
String: Represents a sequence of characters enclosed in single quotes (''), double quotes ("") or backticks (``). Strings are used to store and manipulate textual data.
Symbol: Introduced in ECMAScript 2015, Symbol is a primitive type that represents a unique identifier. Symbols are often used as keys in objects to avoid name collisions.

These primitive types in JavaScript are immutable, meaning their values cannot be changed once created. They are distinct from objects, which are composite data types that can store multiple values and have methods and properties associated with them.

Another property of primitive types in JavaScript is that they are passed by value. This means that when a primitive value is assigned to a variable or passed as an argument to a function, a copy of the value is created and stored in the variable or parameter, and any changes made to the variable or parameter will not affect the original value.

5 - JavaScript is a "compiled" language

In the context of JavaScript, the term compiled can be misleading. Unlike languages such as C++ or Rust, where the source code is directly transformed into machine code before execution, JavaScript goes through a different process. When a JavaScript program is executed, it is first passed through a just-in-time (JIT) compiler built into the JavaScript engine.

During the execution, the JavaScript engine performs several optimizations, including parsing the source code, optimizing the code based on various heuristics, and generating machine code or bytecode for efficient execution. This dynamic compilation process, performed by the JavaScript engine at runtime, helps improve the performance of JavaScript programs.

It is worth noting that the compilation process in JavaScript is different from the traditional pre-compilation step found in languages like C or C++. In JavaScript, there is no separate compilation step that generates an executable file beforehand. Instead, the compilation happens as part of the runtime execution.

Overall, while JavaScript can be considered a compiled language in the sense that it undergoes compilation during runtime, it is more accurate to describe it as an interpreted language with a just-in-time compilation process.

If you want to go deeper, Kyle Simpson explores this topic in detail in his book You Don't Know JS Yet.

Conclusion

JavaScript never ceases to surprise and fascinate developers with its hidden depths and lesser-known features. In this blog post, we explored five intriguing aspects of JavaScript that you might not have been aware of, expanding your understanding of this versatile language.

As you continue your journey with JavaScript, remember that there is always more to explore and learn. Embrace the ever-evolving nature of this dynamic language, and continue to discover new facets that will enhance your development skills.

React Awesome Reveal v3 Beta

Dennis Morello — Sun, 02 Aug 2020 21:43:21 +0000

React Awesome Reveal v3 using Emotion to provide animations is now on beta 🎉 Check it out by adding react-awesome-reveal@beta to your React project.

react-awesome-reveal v2.4.0 released!

Dennis Morello — Sat, 18 Jan 2020 11:12:32 +0000

A new version of react-awesome-reveal has just been released, featuring a reverse option that... reverses the animation direction 👻 It is useful for making elements visible and invisible in a controlled way (form error indicators, badges, notifications and so on)!

Add data-test-id attributes to React apps

Dennis Morello — Fri, 03 Jan 2020 22:10:11 +0000

Meet react-test-attributes, my new library for React apps to add custom data-* attributes to DOM elements. Use it for your E2E tests!

https://www.npmjs.com/package/react-test-attributes

React Awesome Reveal v2 Released

Dennis Morello — Sat, 30 Nov 2019 21:57:18 +0000

React Awesome Reveal has just received a major update featuring zero external dependencies and a cleaner API 🎉 Check it out at github.com/dennismorello/react-awesome-reveal

Demo site

React Awesome Reveal

Dennis Morello — Tue, 26 Nov 2019 18:26:32 +0000

Hi all, I am writing react-awesome-reveal, a React library to animate elements when they appear in the browser viewport. It uses the Intersection Observer API and CSS Animations to be buttery smooth 🚀

Let me know what you think!