DEV Community: Hamed Farazi

Stop Building Websites for Google. Start Building Them for AI

Hamed Farazi — Wed, 19 Aug 2026 10:53:41 +0000

For years, we were told to build websites for search engines.

Add the right keywords.

Write a good title.

Generate a sitemap.

Add structured data.

Build backlinks.

Improve Core Web Vitals.

And, of course, make sure Google can crawl everything.

That worked.

But the way people discover information is changing.

Today, someone might not search for your website at all.

They might ask ChatGPT.

Or Claude.

Or Gemini.

Or another AI system.

And that's where things get interesting.

Because a website can be perfectly optimized for Google and still be terrible for AI to understand.

The New Problem Isn't Just SEO

Imagine you have a website with 10,000 pages.

Google can crawl it.

Your Lighthouse score is great.

Your sitemap is valid.

Your metadata looks perfect.

You have structured data.

From an SEO perspective, everything looks healthy.

Now ask an AI:

"What does this company actually do?"

The answer might still be incomplete.

Or worse, the AI might misunderstand the business entirely.

Why?

Because being crawlable isn't the same as being understandable.

That's the problem I became interested in.

What Does "AI-Friendly" Actually Mean?

I started thinking about a website from the perspective of an AI system rather than a search engine.

An AI needs to answer questions about your website.

That means it needs to understand things like:

What is this website?
Who is it for?
What does this company offer?
Which pages are important?
How are different pieces of content related?
Which information is authoritative?
Can important facts be extracted reliably?
Is the content structured consistently?
Are there conflicting or ambiguous signals?

This isn't exactly SEO.

It's closer to machine-readable communication.

And that requires a different mindset.

So I Built an Experiment

Instead of asking:

"How well optimized is this website for Google?"

I wanted to ask:

"How understandable is this website to AI?"

That led me to build an AI Visibility analysis system.

The idea is simple:

Website
   ↓
Crawler
   ↓
Page Analysis
   ↓
Content Analysis
   ↓
Schema Analysis
   ↓
Internal Link Analysis
   ↓
AI Optimization Analysis
   ↓
AI Visibility Score
   ↓
Actionable Recommendations

The important part is that this isn't based on a few manually selected pages.

The system starts with the actual website.

It crawls the real pages.

Then analyzes what is actually there.

Crawling Is Only the Beginning

A crawler can tell you that a page exists.

That's not enough.

For every page, I wanted to understand several dimensions.

Content

Is the content clear?

Does the page actually explain what it is about?

Are important entities and concepts explicit?

Structure

Are headings meaningful?

Is the document hierarchy logical?

Can an AI distinguish the main topic from navigation, boilerplate and unrelated content?

Structured Data

Does the page expose useful schema?

Is the schema actually consistent with the visible content?

Are important entities represented?

Internal Links

Can an AI understand the relationship between pages?

Or is the website essentially a collection of disconnected documents?

Metadata

Titles and descriptions still matter.

But they're only one signal.

The bigger question is:

Does the metadata agree with the actual content?

The Interesting Part: Scoring

Once you have all this information, you need a way to turn it into something useful.

So instead of returning a giant technical report, I wanted to produce a score.

Something like:

AI Visibility Score
-------------------

Overall Score       85/100

Content Clarity     91
Schema Health       88
Internal Linking    79
Machine Readability 87
AI Optimization     82

The exact score isn't the important part.

The important part is that the score should be explainable.

A number without evidence isn't very useful.

Every Score Should Have Evidence

One of the things I care about most in this system is traceability.

If the system says:

Internal Linking: 79

I don't want the user to just trust an algorithm.

I want to show:

which pages were analyzed
which links were found
which relationships are weak
what rules were triggered
and why the score changed

The same applies to content quality and structured data.

Instead of:

"Your schema is bad."

The system should be able to say:

"These 4 pages declare Organization schema, but the Organization entity isn't consistently represented across the site."

That's much more actionable.

From Analysis to `llms.txt`

Then I reached another interesting question.

If we're trying to make websites easier for AI systems to understand, shouldn't websites explicitly communicate their structure to AI?

That's where llms.txt becomes interesting.

The concept is straightforward:

Instead of making an AI discover everything from thousands of pages, provide a curated machine-readable entry point.

Something like:

# Example Company

> Example Company provides developer tools for...

## Products

- Product A
  https://example.com/product-a

- Product B
  https://example.com/product-b

## Documentation

- Getting Started
  https://example.com/docs/getting-started

- API Reference
  https://example.com/docs/api

The goal isn't to replace the website.

It's to give machines a map.

But There's a Bigger Shift Happening

This isn't really about llms.txt.

It's not even really about AI crawlers.

It's about a fundamental change in how websites are consumed.

For a long time, the primary question was:

"Can a search engine find my page?"

Increasingly, another question matters:

"Can an AI understand my website well enough to represent it correctly?"

Those are different problems.

SEO Isn't Dead

I don't think SEO is going away.

Quite the opposite.

A technically healthy website still needs:

crawlability
indexability
good performance
useful content
semantic HTML
structured data
internal linking
strong information architecture

But these things are becoming part of something larger.

Think of it like this:

                 Website
                    │
        ┌───────────┴───────────┐
        ↓                       ↓
     Search                  AI Systems
        │                       │
       SEO                AI Visibility
        │                       │
        └───────────┬───────────┘
                    ↓
          Machine Understanding

The goal isn't to choose between Google and AI.

The goal is to build websites that machines can understand.

The New Optimization Layer

I think we're moving toward a stack that looks something like this:

Traditional Web
      ↓
Technical SEO
      ↓
Semantic Structure
      ↓
Structured Data
      ↓
Machine Readability
      ↓
AI Visibility

And the interesting thing is that most websites are still somewhere around the middle.

They were designed for humans.

Then optimized for search engines.

But they weren't necessarily designed to be interpreted by language models.

What I Learned Building This

The biggest lesson wasn't about AI.

It was about abstraction.

A website contains an enormous amount of information.

Humans can navigate it intuitively.

Machines need signals.

Those signals can come from:

URLs
headings
semantic HTML
metadata
schema
links
content hierarchy
consistent entities
explicit relationships

When these signals agree with each other, the website becomes much easier to understand.

When they contradict each other, even a powerful AI can struggle.

The Future Website Might Be Designed for Three Audiences

We used to think about two:

1. Humans
2. Search Engines

I think we're adding a third:

3. AI Agents

And AI agents are different from search engines.

A search engine wants to discover and rank documents.

An AI agent wants to understand information and use it to answer questions or perform actions.

That's a much bigger responsibility for the web.

So, Should You Start Optimizing for AI?

Yes.

But don't start by stuffing your website with AI-generated text.

Don't add meaningless schema everywhere.

Don't create thousands of pages just because an LLM can generate them.

Instead, start with something much simpler:

1. Make your website understandable.

If you can't explain what a page is in one sentence, an AI probably won't have an easy time either.

2. Make important entities explicit.

Companies, products, people, organizations and concepts should have consistent representations.

3. Build a strong information architecture.

Your website shouldn't feel like a pile of URLs.

4. Use structured data correctly.

Schema should describe reality, not just exist for the sake of SEO.

5. Make relationships obvious.

Internal links aren't only navigation.

They're signals about how information is connected.

6. Measure it.

This is the part we're still figuring out.

SEO has decades of tools and metrics.

AI visibility is still a relatively new space.

That's what makes it interesting.

We're Entering the "Answer Engine" Era

The web was built around documents.

Search engines organized those documents.

Social networks organized people and attention.

Now AI systems are starting to organize knowledge.

And when the interface becomes an AI answer instead of a list of ten blue links, the optimization problem changes.

The question is no longer only:

"How do I rank?"

It becomes:

"How do I become the source an AI understands, trusts and chooses to use?"

That's a very different question.

And I think we're just getting started.

Final Thought

Maybe the next generation of web development won't be about building websites that are optimized for humans or machines.

It'll be about building websites that are understandable to both.

Humans need good UX.

Search engines need crawlable, structured content.

AI systems need context, relationships and clear signals.

The best websites will increasingly provide all three.

Don't stop building for Google.

Just don't build only for Google anymore.

Burger Atelier — The Burger, Reimagined 🍔

Hamed Farazi — Tue, 11 Aug 2026 12:21:21 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

For this challenge, I wanted to take a familiar comfort food and give it a more refined digital experience.

I built Burger Atelier, a modern landing page centered around the idea of burgers as more than just fast food — they can be crafted, customized, and presented like an experience.

The goal was to create a landing page that feels polished while keeping the experience simple and intuitive.

Highlights
🍔 A bold food-focused visual design
📱 Responsive layout across screen sizes
✨ Interactive UI elements and micro-interactions
🎯 Clear calls-to-action and visual hierarchy
♿ Accessibility-conscious structure and interactions
⚡ Modern React-based frontend
🧩 Reusable components and clean project structure
Demo

🌐 Live Demo:

frontend-challenge-comfort-food-edi-alpha.vercel.app

💻 Source Code:

HamedFarazi / Frontend-Challenge---Comfort-Food-Edition-Perfect-Landing

Perfect Landing: Comfort Food

Burger Atelier

Premium interactive burger studio for the DEV Community Frontend Challenge — Comfort Food Edition.

Run

npm install
npm run dev
npm run build

Stack

React · TypeScript · Vite · Tailwind CSS v4 · CSS burger craft

View on GitHub

Journey

I approached the project by first thinking about how a food brand could communicate its personality through its landing page.

Instead of treating the page as a collection of sections, I focused on creating a visual flow that guides the user from the hero section toward the menu and the main call-to-action.

One of the things I enjoyed most was balancing the visual side of the design with practical frontend considerations. A food landing page can easily become visually heavy, so I tried to keep the interactions clear and the content easy to scan.

Building the project with React also gave me the opportunity to structure the UI into reusable pieces rather than treating the page as one large component.

What I learned

This challenge was a good reminder that a polished landing page isn't only about making things look good.

The small details matter:

How quickly users understand what the product is
Whether the primary action is obvious
How the layout behaves on smaller screens
Whether interactive elements feel intentional
How accessible the experience remains beneath the visual layer

I'm particularly happy with how the final design combines a playful food theme with a more premium visual direction.

What's Next?

I'd like to continue experimenting with the concept by adding more interactive ordering flows, richer menu interactions, and potentially turning Burger Atelier into a small multi-page restaurant experience.

Thanks to the Frontend Challenge team for putting together this challenge! 🙌

Built with React and modern frontend tools.

🍔 The Perfect Burger — CSS Art

Hamed Farazi — Tue, 11 Aug 2026 11:25:10 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

🍔 The Perfect Burger

Inspiration

For this challenge, I wanted to create something familiar, fun, and comforting: a classic burger.

Instead of using images or pre-made assets, I decided to build the entire burger from scratch using HTML and CSS.

Every ingredient is created with CSS, including the buns, lettuce, tomato, onion, melted cheese, and grilled beef patty.

The goal was to make something that looks like a burger at first glance, but becomes more interesting when you discover that the entire artwork is built with HTML and CSS.

Demo

🚀 Live Demo: https://frontend-challenge-comfort-food-edi.vercel.app/

💻 Source Code: https://github.com/HamedFarazi/Frontend-Challenge---Comfort-Food-Edition

You can also interact with the burger to reveal and separate its individual ingredients.

✨ Features

🍞 CSS-crafted toasted buns
🥩 Grilled beef patty with CSS texture
🧀 Melted cheese with organic drips
🥬 Layered lettuce
🍅 CSS tomato slices
🧅 CSS onion rings
✨ CSS gradients and shadows
🎬 Interactive ingredient reveal mode
🖱️ Hover and 3D interactions
♿ Keyboard accessible interactions
📱 Responsive design
🌓 prefers-reduced-motion support

🛠️ Built With

HTML5
CSS3
Vanilla JavaScript

🎨 CSS Techniques

Gradients
Pseudo-elements
Clip-path
CSS transforms
CSS animations
Box shadows
CSS variables
3D perspective

Journey

I started this project with a simple idea: create a burger using only HTML and CSS.

The first version was intentionally simple, but as I worked on it, I focused on making the ingredients feel more organic, dimensional, and visually appetizing.

The most challenging parts were creating the melted cheese, the grilled texture of the beef patty, and making all of the ingredients feel like they were physically stacked together.

I used CSS gradients, pseudo-elements, clip-path, transforms, shadows, and animations to create the different ingredients and their textures.

One of my favorite parts is the interactive reveal mode. Instead of keeping the burger as a static illustration, users can separate the ingredients and see each layer individually.

This also became a way to demonstrate that the burger is actually built from individual HTML/CSS elements.

What's Next?

I'd like to continue experimenting with CSS-based food illustrations and push the interaction and visual details even further.

Thanks for checking out my submission! 🍔

Why (and When) You Should Actually Use useMemo and useCallback

Hamed Farazi — Tue, 11 Aug 2026 08:29:43 +0000

If you've spent any time in a React codebase, you've probably seen useMemo and useCallback sprinkled everywhere — sometimes on every single function and computed value, "just in case." The irony is that this habit often makes an app slower, not faster, while also making the code harder to read.

This article is about building an honest mental model for these two hooks: what they actually do under the hood, when they genuinely help, and when they're just noise.

What these hooks actually do

useMemo and useCallback don't make anything "faster" by default. They cache a value between renders and only recompute it when its dependencies change.

const value = useMemo(() => computeExpensiveValue(a, b), [a, b]);
const fn = useCallback(() => doSomething(a, b), [a, b]);

useCallback(fn, deps) is really just useMemo(() => fn, deps). Same mechanism, different return type (a function reference instead of a value).

Two things matter here:

The caching itself has a cost. React has to store the previous dependency array, compare it on every render, and hold onto the cached value in memory.
You only benefit if something downstream actually cares about referential stability or expensive recomputation.

If neither of those is true, you're paying the comparison cost for zero benefit.

The case where it's obviously worth it: expensive computations

This one is uncontroversial. If you have a genuinely heavy calculation — sorting a large array, filtering thousands of rows, running some numeric computation — recomputing it on every render (including renders triggered by unrelated state) is wasteful.

function ProductList({ products, filters }) {
  const filtered = useMemo(
    () => products.filter(p => matchesFilters(p, filters)),
    [products, filters]
  );

  return <List items={filtered} />;
}

Without useMemo, every re-render of ProductList — even one triggered by, say, a tooltip's hover state — would re-run the filter over the whole array. With it, the filter only reruns when products or filters actually change.

The key word is expensive. Filtering 20 items is not expensive. Filtering 20,000 items, or running a computation with real algorithmic weight, is. Don't reach for useMemo reflexively — profile first, or at least reason about the actual cost.

The case that trips people up: referential stability

This is where most of the confusion lives. useCallback and useMemo matter for referential stability in two situations:

1. When a value or function is a dependency of another hook.

function SearchBox({ onSearch }) {
  const debouncedSearch = useMemo(
    () => debounce(onSearch, 300),
    [onSearch] // if onSearch changes identity every render, this debounce is recreated every time
  );
  // ...
}

If onSearch isn't stable, useEffect, useMemo, or a custom hook relying on it as a dependency will re-run constantly, potentially defeating the entire purpose of the debounce, subscription, or cache it's feeding into.

2. When a value is passed to a memoized child component.

const ExpensiveChild = React.memo(function ExpensiveChild({ onClick }) {
  // heavy render logic
});

function Parent() {
  const [count, setCount] = useState(0);

  // Without useCallback, this is a NEW function every render,
  // which defeats React.memo on ExpensiveChild entirely.
  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      <ExpensiveChild onClick={handleClick} />
    </>
  );
}

Here, React.memo on ExpensiveChild only pays off if the props it receives are stable. If handleClick is a new reference on every render, React.memo does nothing — the child re-renders anyway, and you've added the overhead of React.memo's comparison for no benefit.

This is the important part: useCallback without React.memo (or a dependency array somewhere downstream) usually does nothing useful. The two are a pair. If nothing consumes the stable reference, you're just adding bookkeeping.

When it's not worth it

Simple values or inline functions passed to plain DOM elements. <button onClick={() => setOpen(true)}> does not need useCallback. DOM elements aren't memoized components; a new function reference every render costs essentially nothing.
Cheap computations. const total = a + b doesn't need useMemo. The comparison overhead of the hook can genuinely exceed the cost of just recalculating.
"Just in case" usage without a memoized consumer. If nothing downstream is React.memo-wrapped and nothing uses the value as a dependency, the memoization has no one to benefit from it.
Values that change on every render anyway. If a dependency changes every render, useMemo will recompute every time too — you get the comparison cost and the recomputation.

A practical mental checklist

Before adding useMemo or useCallback, ask:

Is this computation actually expensive, or does it just look intimidating? (Measure if unsure.)
Does something downstream depend on referential equality — a React.memo child, a useEffect dependency, a custom hook's cache key?
Do the dependencies change rarely relative to how often the component re-renders? If they change every time anyway, memoization buys nothing.

If the answer to #1 or #2 is no, you probably don't need the hook.

A note on the React Compiler

It's worth mentioning: the React team has been building an automatic compiler (React Compiler, formerly "React Forget") specifically to memoize things like this automatically, precisely because manual useMemo/useCallback placement is easy to get wrong and tedious to maintain. That's a strong signal about how the React team itself views manual memoization — as a mechanism you should reach for deliberately, not a reflex.

Takeaway

useMemo and useCallback are not performance switches you flip on by default. They're targeted tools for two specific problems: avoiding expensive recomputation, and preserving referential stability for something that actually checks for it. Used with intent, they meaningfully help. Used everywhere, they add cognitive overhead and runtime cost while often fixing nothing at all.

Where to get cover images for a post like this: for genuinely free-to-use, no-attribution-needed photos, Unsplash and Pexels are the standard choices for dev.to-style covers — search something like "code" or "abstract programming." For a more on-topic illustration (e.g. a diagram-style cover), you can also generate a simple custom SVG/graphic yourself — dev.to covers are just images, so anything royalty-free works.

How I Used BFS to Find the Shortest Route in Tehran Metro with React

Hamed Farazi — Mon, 10 Aug 2026 22:48:07 +0000

When I started building Metrino, a Tehran Metro route planner, I had a simple question:

«How can I find the shortest route between two metro stations?»

The UI was only one part of the problem. Underneath the map and station selectors, I needed a way to represent the Tehran Metro network and calculate a route between two stations.

The solution was to model the metro network as a graph and use Breadth-First Search (BFS) to find the shortest path.

🚇 Turning the Metro Into a Graph

Instead of thinking about the metro as a visual map, I represented it as a graph.

Each station is a node.

Each connection between two stations is an edge.

For example:

Station A
│
▼
Station B ─── Station C
│
▼
Station D

In my data model, each station contains a list of connected stations.

This means I can ask:

«"Which stations can I reach directly from this station?"»

The application builds a bidirectional adjacency map when the metro data is initialized:

const adj = new Map>();

this._stations.forEach((s) => {
if (!adj.has(s.id)) adj.set(s.id, new Set());

s.connectedStationIds.forEach((nid) => {
adj.get(s.id)!.add(nid);

// Add reverse direction
if (!adj.has(nid)) adj.set(nid, new Set());
adj.get(nid)!.add(s.id);

});
});

This gives the route finder a structure that is easy to traverse.

🧭 Why BFS?

For the first version of the route planner, I wanted to minimize the number of station-to-station hops.

That's where BFS works well.

Breadth-First Search explores a graph level by level:

Start
│
├── A
├── B
└── C
│
├── D
├── E
└── F

It first explores the stations closest to the starting station, then moves to the next level.

Because every connection has the same cost in this version of the problem, the first route BFS finds to the destination is the route with the fewest hops.

💻 The Actual BFS Implementation

Here is the actual "findPath" implementation from Metrino:

findPath(fromId: string, toId: string): string[] | null {
if (fromId === toId) return [fromId];

const visited = new Set();

const queue: Array<{ id: string; path: string[] }> = [
{ id: fromId, path: [fromId] },
];

visited.add(fromId);

while (queue.length > 0) {
const { id, path } = queue.shift()!;

const neighbors = this._adjacency.get(id) ?? [];

for (const neighbor of neighbors) {
  if (neighbor === toId) {
    return [...path, neighbor];
  }

  if (!visited.has(neighbor)) {
    visited.add(neighbor);

    queue.push({
      id: neighbor,
      path: [...path, neighbor],
    });
  }
}

}

return null;
}

Let's break it down.

Handle the same station

if (fromId === toId) return [fromId];

If the origin and destination are the same station, there is nothing to calculate.

Keep track of visited stations

const visited = new Set();

Without this, the algorithm could keep visiting the same stations again and again.

I immediately mark the starting station as visited:

visited.add(fromId);

Create the queue

const queue: Array<{ id: string; path: string[] }> = [
{ id: fromId, path: [fromId] },
];

The queue contains the station we're currently exploring and the path that led to it.

For example:

{
id: "station-b",
path: ["station-a", "station-b"]
}

This makes it easy to return the complete route once we reach the destination.

Explore the graph

while (queue.length > 0) {

As long as there are stations waiting to be explored, BFS continues.

We remove the first item from the queue:

const { id, path } = queue.shift()!;

Then get all directly connected stations:

const neighbors = this._adjacency.get(id) ?? [];

Check the destination

if (neighbor === toId) {
return [...path, neighbor];
}

As soon as BFS reaches the destination, we return the complete station sequence.

For example:

Station A
↓
Station B
↓
Station C
↓
Station D

The returned result would look like:

[
"station-a",
"station-b",
"station-c",
"station-d"
]

Add unvisited stations to the queue

if (!visited.has(neighbor)) {
visited.add(neighbor);

queue.push({
id: neighbor,
path: [...path, neighbor],
});
}

This is what allows BFS to move through the network level by level.

🔄 What About Line Transfers?

Finding the shortest path is only part of the problem.

Tehran Metro has multiple lines, so after finding the station path, I also need to determine where passengers change lines.

The route service looks at consecutive stations and finds their shared line:

private _getCommonLine(a: Station, b: Station): number | null {
for (const line of a.lines) {
if (b.lines.includes(line)) return line;
}

return null;
}

Then the route builder can detect when the route changes from one line to another.

For example:

Line 1
│
│
▼
Station A
│
▼
Transfer Station
│
│
▼
Line 4
│
▼
Station B

The transfer is recorded separately from the BFS path.

⏱️ Estimating Travel Time

BFS gives me the route, but it doesn't tell me how long the journey will take.

So after finding the path, Metrino calculates an estimated travel time using:

approximate distance between stations
an average train speed
station dwell time
transfer time

The current implementation uses:

const TRANSFER_PENALTY_MIN = 3;
const STATION_DWELL_SEC = 30;
const AVG_SPEED_KMH = 40;

The total estimate is then built from these values.

These are estimates, not official Tehran Metro schedules.

🧩 Separating the Algorithm From the UI

One thing I wanted to avoid was putting route calculation directly inside React components.

Instead, I separated the responsibilities:

React UI
↓
MetroRouteService
↓
MetroDataService
↓
Metro Graph / Metro Data

"MetroDataService" handles the station, line, connection, and adjacency data.

"MetroRouteService" takes the resulting path and turns it into a complete route containing:

origin
destination
station sequence
segments
transfers
distance
estimated time

This separation makes the UI much easier to work with.

📈 What's Next?

BFS was a good starting point because the first version of Metrino only needed to minimize the number of station hops.

But the real-world "best route" isn't always the route with the fewest stations.

For example, a slightly longer route might be better if it has fewer transfers or takes less time.

That's why one of the next improvements I'd like to explore is weighted pathfinding, using algorithms such as Dijkstra's algorithm or A*.

The goal would be to consider things like:

Station count

Travel time
Transfer penalties

instead of only counting station hops.

🚀 What I Learned

The biggest lesson from building this feature was that many problems that look like UI problems are actually data structure and algorithm problems.

The metro map is a UI.

But underneath that UI, it's a graph.

Once I represented the metro network as a graph, route calculation became much easier to reason about.

BFS gave me a simple and reliable starting point, and it was enough to power the first version of the route planner.

🚇 Try Metrino

I built Metrino as a Persian-first Tehran Metro web application with React, TypeScript and Vite.

Live Demo: https://metrino.vercel.app/

GitHub: https://github.com/HamedFarazi/metroapp

The project is open source, and I'm continuing to improve the routing, maps, PWA experience, and accessibility.

Thanks for reading 💫

DEV Community: Hamed Farazi

Stop Building Websites for Google. Start Building Them for AI

The New Problem Isn't Just SEO

What Does "AI-Friendly" Actually Mean?

So I Built an Experiment

Crawling Is Only the Beginning

Content

Structure

Structured Data

Internal Links

Metadata

The Interesting Part: Scoring

Every Score Should Have Evidence

From Analysis to llms.txt

But There's a Bigger Shift Happening

SEO Isn't Dead

The New Optimization Layer

What I Learned Building This

The Future Website Might Be Designed for Three Audiences

So, Should You Start Optimizing for AI?

1. Make your website understandable.

2. Make important entities explicit.

3. Build a strong information architecture.

4. Use structured data correctly.

5. Make relationships obvious.

6. Measure it.

We're Entering the "Answer Engine" Era

Final Thought

Burger Atelier — The Burger, Reimagined 🍔

HamedFarazi / Frontend-Challenge---Comfort-Food-Edition-Perfect-Landing

Perfect Landing: Comfort Food

Burger Atelier

Run

Stack

🍔 The Perfect Burger — CSS Art

🍔 The Perfect Burger

Inspiration

Demo

✨ Features

🛠️ Built With

🎨 CSS Techniques

Journey

What's Next?

Why (and When) You Should Actually Use useMemo and useCallback

What these hooks actually do

The case where it's obviously worth it: expensive computations

The case that trips people up: referential stability

When it's not worth it

A practical mental checklist

A note on the React Compiler

Takeaway

How I Used BFS to Find the Shortest Route in Tehran Metro with React

From Analysis to `llms.txt`