DEV Community: Alex

The benchmark everyone cited for "fastest backend" was archived in March, and the reason is the interesting part

Alex — Mon, 14 Sep 2026 18:18:22 +0000

Ask which backend is fastest and somebody shows you a bar chart. For twelve years that chart came from the TechEmpower Framework Benchmarks, and in March 2026 the repository went into archived mode after a final round covering more than 330 framework implementations.

The archival is more useful than anything in the last round, because of why it happened.

What the chart was actually measuring by the end

The criticisms that preceded the archive are the part worth keeping. The test platform had barely changed in years. Results were being capped by the harness rather than by the frameworks under test. And entries were allowed to use low-level optimisations no team would ever ship in a real product, which meant a framework could top the chart running code its own documentation would advise against.

There is a successor attempt, HttpArena, aiming at the same job with HTTP/2 and WebSocket support and deliberately realistic implementations. Until it has comparable coverage, treat every "fastest backend 2026" chart as a rough ordering of ceilings rather than as a prediction about your application.

For the record, the final round's Fortunes test — the most application-like of the suite, since it does a database read, a sort and an HTML render — put ASP.NET on C# around 610,000 requests per second, Fiber on Go around 338,000, Actix on Rust around 320,000, Spring on Java around 244,000 and Express on Node around 78,000. Read the ordering, not the figures: Microsoft donated 56-core servers on a 40Gbps network partway through the project, which lifted network-bound results by three to four times and made absolute numbers incomparable with earlier rounds.

Where your response time actually goes

On a typical business API, the language spends single-digit milliseconds and everything else spends the rest.

An unindexed query. An N+1 pattern firing 200 queries where one would do. A synchronous call out to a payment or CRM provider that is having a slow afternoon. A missing cache on a response that changes hourly. Any one of those costs more than the entire gap between the fastest and the slowest stack in that list.

This is why rewriting a slow Node service in Go so often disappoints the people who authorised it. If 480 milliseconds of a 500 millisecond response is a query waiting on a database, moving the remaining 20 milliseconds to 5 is a three per cent improvement in exchange for a full rewrite. Fixing the query is a ninety per cent improvement in exchange for an afternoon.

What I actually choose, and why it is mostly not about speed

Node with TypeScript is my default, and the reason is not performance. It is that it is the same language as the front end, so types, validation logic and utilities are shared rather than reimplemented in two places and then kept in sync by hand forever. For I/O-bound work, which is most business software, the event loop is genuinely well suited to the shape of the problem — and note that the table above measures Express, not the faster runtimes now available in the same ecosystem.

Go is what I reach for when a service has to hold many thousands of concurrent connections cheaply, or when a single small binary with predictable memory is operationally valuable to whoever is on call.

Python earns its place wherever machine learning or data tooling is involved, because the libraries are there and nothing else is close, and the heavy numerical work is running in optimised native code anyway.

Java is the right answer when it is already the house stack and a team exists who can maintain it. That is not a consolation prize. It is usually the single strongest argument available.

Rust I recommend rarely and specifically: sustained CPU-bound throughput where the hosting bill scales with efficiency, so the efficiency is a line on the P&L rather than a preference.

When the language genuinely is the bottleneck

It does happen, and pretending otherwise is its own kind of dishonesty.

Real-time systems holding tens of thousands of persistent connections. Per-request CPU work like image or video transformation. High-frequency data ingestion. Workloads where compute cost is a material business number rather than a rounding error.

The tell is measurement, not intuition. If profiling shows the CPU saturated inside your own code rather than time spent waiting on other systems, the language matters and you should act on it. Otherwise you have a database, caching or architecture problem wearing a language problem's clothes, and the rewrite will cost a quarter and move nothing.

Perceived speed is a different number, and it is usually cheaper to buy

There is a category error buried in the original question that is worth naming, because it redirects a lot of wasted effort.

"Which backend is fastest" assumes the user is waiting on the backend. Frequently they are waiting on the front end waiting on the backend, which is not the same thing at all. A server-rendered page that shows content immediately and fills in data afterwards feels faster than a client-rendered page that shows a spinner while calling the identical API at the identical speed.

Same backend. Same response time. Different experience, and the second one is what generates the complaint that reaches the engineering team as "the API is slow".

I mention it because the fix is usually an order of magnitude cheaper than anything on the backend. Rendering the shell on the server, streaming the parts as they resolve, and being deliberate about which data actually has to arrive before the page is useful will beat a language migration on almost any project, and it can ship in a sprint.

Measure what the user waits for. It is often not what you think you are optimising.

Why Python stays on the list despite the numbers

Every version of this comparison puts Python near the bottom on throughput, and every version of this comparison is then contradicted by what teams actually build.

Two reasons, and both are real rather than inertia. For anything involving AI, data processing or scientific work, the library ecosystem has no serious competitor, and being able to use the tool that exists beats being able to run a tool you have to write. And the heavy numerical work is not running in the interpreter anyway — it is running in optimised native code that Python is orchestrating, which means the interpreter speed applies to the thin layer rather than to the work.

That is the general form of the argument and it applies more widely than Python. Interpreter or runtime speed matters in proportion to how much of the actual work happens there. For a service that spends its life marshalling JSON between a database and an HTTP response, that proportion is small, and the benchmark that measures it is measuring the least significant part of the job.

The criteria that beat raw speed

Who maintains this in three years, and can you hire them. How mature the libraries are for the specific integrations you need, not the ones in the tutorial. How fast a fix ships when something breaks at nine in the morning. What the hosting costs at your actual traffic rather than at 600,000 requests per second.

A stack that is four times slower on a synthetic benchmark and twice as fast to change is the better commercial choice for almost every business application anyone reading this is likely to build.

Fast enough is a real engineering target, and it is a better one than fastest. Define it — say, 200 milliseconds at the 95th percentile under expected load — write it down, and then pick the stack your team can keep meeting it with for years.

What to do now that the chart is gone

Benchmark your own workload, with your own data shape and your own query patterns. A synthetic hello-world throughput number has never predicted real application performance well, and its twelve-year run as the default answer to this question was always slightly accidental.

The honest version of "which backend is fastest" is that the question is answerable and almost never decisive.

Read the full version

This is the condensed version. The full article carries the complete Round 23 table with the hardware caveat in full, the per-stack notes on what each one is realistically good at, and the questions clients actually ask before a rewrite.

Which Backend Is Fastest? Go vs. Node vs. Java vs. Python

Sources

The throughput figures are from the final published round of the TechEmpower Framework Benchmarks, and the hardware change that lifted network-bound results is documented in TechEmpower's own Round 23 announcement. The 24 March 2026 archival, the stagnation criticisms and HttpArena as the proposed successor are recorded in this post here on DEV. Where the time actually goes on a business API is my own experience of profiling other people's.

If you have run a language rewrite specifically for performance, I would like to hear what the before-and-after actually looked like — particularly whether the profile said what you expected before you started.

A 100 PageSpeed score does not contain INP, and that is the most expensive thing about it

Alex — Sun, 13 Sep 2026 21:25:04 +0000

A 100 in PageSpeed Insights is one of the very few numbers in this job you can chase to a literal maximum, which is exactly why people chase it. It is a score, not a feeling, and getting it forces real fixes.

It is also a lab score: one simulated load, on a fixed device and network profile, run once. Two of the three things that most determine whether a site feels fast to a real person are not in it at all. Here is what the number is made of, and what it never sees.

What the 100 points are actually made of

The performance score is a weighted average of five metrics, and the weights are not close to equal. Total Blocking Time is 30 per cent. Largest Contentful Paint is 25. Cumulative Layout Shift is 25. First Contentful Paint is 10. Speed Index is 10.

TBT alone carries three times the weight of FCP, which is why two sites with an identical "feels fast" first impression can land twenty points apart. One of them has a script blocking the main thread for two seconds after that first paint, and the score punishes exactly that.

Each metric is scored on its own curve, and the curve is not linear. Chrome's documentation puts it on a log-normal distribution built from real HTTP Archive data, with two fixed points: the 25th percentile of real sites scores 50, and the 8th percentile scores 90. Between roughly 50 and 92 the relationship is close to linear, so shaving time off a slow metric buys a predictable number of points. Above 96 it is not. The same time saved buys a fraction of a point.

That is the mathematical reason the last few points cost disproportionately more than the first sixty, and it is a fact about the scoring function rather than about your code.

Why the main thread does the most damage

TBT measures every stretch of time the main thread is blocked for more than 50 milliseconds between First Contentful Paint and interactivity, added together.

It is rarely one slow thing. It is a dozen small ones: a bundle that parses and executes before anything else can run, a chat widget loading eagerly, an analytics tag, a carousel library doing DOM work for something nobody has scrolled to. Each is harmless in a code review. Stacked, they are what a visitor experiences as a page that looks ready and does not respond when tapped.

The fix is rarely "write faster code". It is mostly sequencing. Defer what is not needed for the first paint. Split the bundle so the browser is not parsing code for features below the fold. Load third-party scripts after first interaction rather than on page load, since none of them are why anyone came.

Most sites lose more points to script execution than to image weight, even though images get blamed first and fixed first.

Why the score moves when nothing changed

A single Lighthouse run is a sample, not a measurement. Chrome's own scoring documentation lists A/B tests, ad-serving changes, shifting internet routing, device load, browser extensions and antivirus software as normal sources of run-to-run variance, before anything you deployed enters into it.

Ninety-four one minute and eighty-eight the next is usually not a regression. It is the same page measured under slightly different conditions. Judge a trend across several runs rather than a single number somebody screenshotted for a status report.

Desktop and mobile are also not one test with a label swapped. Since Lighthouse v6 they run on separate scoring curves calibrated to different real-world data, and mobile is throttled to a slower, more constrained profile deliberately. A page scoring 100 on desktop and 74 on mobile is not a bug in the tool. It is the tool doing the one thing it is for.

The gap between a lab 100 and a good experience

PageSpeed Insights shows lab and field data side by side and Google is explicit that it does not combine them. The 0 to 100 score is based entirely on the lab run. Field data from the Chrome UX Report is reported separately and does not touch that number.

Their documentation states it about as plainly as documentation ever does: having good lab data does not necessarily mean real-user experiences will also be good.

So a 100 tells you the simulated load on the tested device and network was excellent. It does not tell you what happened on a three-year-old Android phone on patchy 4G, which is where a meaningful share of real traffic actually lives. Core Web Vitals — field data at the 75th percentile of real visits over a rolling window — is the number Google's ranking systems actually read, and a site can hold 100 in the lab while failing it in the field.

The metric the score does not contain at all

Interaction to Next Paint is not in the performance score in any form, at any weighting.

INP replaced First Input Delay as a Core Web Vital on 12 March 2024, and unlike FID it does not stop at the first interaction. It observes the latency of every click, tap and keypress across the whole lifespan of a visit and reports a single value representing roughly the worst of them. Good is 200 milliseconds or less at the 75th percentile; above 500 is graded poor.

A lab run cannot produce that number honestly, because a lab run does not interact with the page. It loads it and stops. Chrome's guidance is explicit that a lab INP figure depends entirely on which interactions were performed during measurement, and that many lab tools do not report one at all. TBT is the closest proxy and it only covers the window around page load.

The practical consequence is specific and very common: a page scores 100, and then a menu takes 600 milliseconds to open on a mid-range phone because an event handler does too much work per tap. The score never saw it, because nobody tapped anything.

The navigations the score never sees either

Chrome's usage data puts one in ten navigations on desktop and one in five on mobile as back or forward. Those, if you let them, are not loads at all — the back/forward cache keeps a paused snapshot in memory and restores it almost instantly with no network involved.

PageSpeed Insights will never show you this. It is not part of the score on any run.

It is, however, a large part of whether a site feels fast, and it is mostly a matter of not disqualifying yourself. Never use the unload event, which web.dev states about as plainly as it states anything — move that work to pagehide or to visibilitychange, which are more reliable on mobile anyway. Cache-Control: no-store may make a page ineligible. Open IndexedDB, fetch, WebSocket or WebRTC connections will do it, as will a non-null window.opener. DevTools will test a page and name the reason it failed.

Fixing this is usually deleting something rather than building something, which makes it the cheapest performance work available and the easiest to never get round to.

The order the fixes actually go in

Measure several runs first, so you are optimising a range rather than an outlier. Then TBT, because it is 30 per cent of the score and almost always the largest single loss. Then LCP — and identify what the largest element actually is, because it is frequently a heading in a webfont rather than the hero image everyone assumes. Then CLS, which is usually the cheapest of the three: explicit dimensions on images and embeds, reserved space for anything injected late, and a font strategy that does not reflow.

Only after those three sit green is the 94-to-100 gap worth anyone's time, and by then it is two or three specific items rather than a project.

And be selective about where you spend it. The log-normal curve makes the last few points the most expensive on the page by a wide margin, and Chrome's own colour banding draws no distinction between 90 and 100 — both are simply "good". The homepage and paid landing pages can earn the last mile. A blog post two clicks deep will not.

Read the full version

This is the condensed version. The full article has the metric-by-metric breakdown with what moves each one, the full scoring-curve explanation, and the questions clients ask when the number and the experience disagree.

How to Get a 100 PageSpeed Score, and What It Means

Sources

The metric weights, the log-normal curve and the sources of run-to-run variance are documented in Lighthouse performance scoring. That the displayed score is lab-only, and that good lab data does not necessarily mean good real-user experiences, is stated in About PageSpeed Insights, with field-data eligibility covered in the CrUX methodology. The INP definition, thresholds and lab caveat are on web.dev, and its promotion to a Core Web Vital on 12 March 2024 is here. The navigation share and the eligibility blockers are from back/forward cache. The fixing order is mine.

If you have a page holding 100 in the lab and failing Core Web Vitals in the field, I would like to know which metric broke first — my guess is INP nearly every time, but I would rather have other people's data than my guess.

Startups ask for the cheapest option first. It is not a question about price.

Alex — Thu, 03 Sep 2026 23:11:21 +0000

Startup enquiries are more alike than founders expect. Different products, different markets, different stages, and the same ten requests, usually in the same order, often inside the first ten minutes.

That is not a complaint. Almost every one of them is a reasonable thing to want. But a request is not a brief, and the distance between what somebody asks for and what they are actually trying to buy is where most of a first budget gets spent on the wrong thing. What follows is that list ordered by how often each one comes up, which is a different list from the one I would write if I ordered it by importance.

One number frames the whole thing. In CB Insights' analysis of startup post-mortems, the most cited cause of death was running out of money, at 38%, with no market need close behind at 35%. Nothing below beats either of those. A website cannot save a product nobody wants, and an expensive one will help you run out of cash faster.

The order is frequency, not importance

Ordering by importance produces a much more flattering list, with strategy at the top and the logo somewhere near the bottom. It is also a list about the agency rather than about what founders actually say, which makes it useless as a guide to your own first conversation.

So the ranking here is how often each request appears. The one at the bottom shows up in maybe one enquiry in five. The one at the top shows up in almost all of them, frequently before anybody has described what the product does.

The cheapest option is a risk question

The single most common opening is some version of what is your cheapest option, and about half the time it arrives before the product has been explained at all. That ordering is the tell. If it were really a question about price it would come after the scope, not before it.

What is actually being asked is a question about risk. The founder does not know whether this will work, has a fixed and usually small amount of money, and is trying to find the smallest cheque that could possibly be enough. That is not stinginess. It is the same instinct that keeps a company alive long enough to find out whether anyone wants the thing.

The honest answer, and I will give it against my own interest, is that the cheapest genuinely useful thing is one page that does one job, and for a company that has not yet proven demand that is frequently the correct purchase rather than a compromise. One finished page will not carry a business through a Series A, and it is not supposed to. It is supposed to tell you whether to keep going.

The distinction that actually matters is not cheap against expensive. It is configured against developed. Below a certain budget you are buying an assembled site on an existing platform, with the ceiling that implies. Above it you are buying something built, which costs more and does not have that ceiling. Both are legitimate purchases. Being sold the first while being charged for the second is not, and it is common enough that asking which one you are getting is a reasonable opening question.

The deadline is the only genuinely fixed constraint

Second most common is a date. Demo day, the close of a round, a trade fair, an investor meeting on the fourteenth. It is almost always real, almost always immovable, and almost always attached to a scope that assumes six weeks of work.

This is the one request on the list where the constraint is not negotiable, and treating it as a preference is how agencies produce a genuinely good site that arrives eight days after the event it was for. The date is fixed, so the scope has to move, and it should move deliberately rather than by whatever happens to be unfinished on the morning of.

Cut pages before you cut quality. One page that is actually finished, fast, properly written, with a form somebody tested, beats a nine page site with three placeholder sections, and it beats it in front of exactly the audience you are worried about. The rest can follow in month two, by which point you will know which parts anyone asked about.

Worth saying plainly, because it is uncomfortable and true: on projects that miss their date, the long pole is usually the client's own review cycles rather than the build.

Ranking is a timeline, not a build setting

Will it rank on Google gets asked as though it were a checkbox in the build. Sometimes it arrives pre-packaged as is it SEO optimised, which is the version somebody else already sold.

The build determines whether you can rank and does nothing at all about when. A new domain with twelve pages does not rank for anything competitive in its first month, and Google's own starter guide says outright that changes can take anywhere from a few hours to several months to be reflected in search. Realistically you are looking at something like half a year before organic is a channel rather than a rounding error.

What a good build actually buys is that nothing is in the way. Clean URLs, real server rendered content, fast pages, correct metadata, a sitemap that is not lying about what exists. That is worth having and it is not the same product as ranking. For the gap between launch and traction, you buy traffic, and you should budget for it rather than discovering the timeline in month three.

The app is usually about the stores, not the product

Somewhere in the middle of the list, reliably, is and eventually a mobile app, where eventually means this quarter. Frequently before the web product has a single active user.

What is being bought here is seriousness. An app in the stores feels like proof the company is real in a way a website does not. There are startups whose product genuinely has to be native, anything leaning on the camera, on background location, on offline use, or on push as the core loop. There are far more where the app is a wrapper around pages that already work fine in a browser.

The cost that gets underestimated is not the build, it is the release cycle. Native means two codebases, an Apple Developer Program membership at ninety-nine dollars a year, a one-time twenty-five dollar Google Play registration, and app review sitting between you and every fix you ship. On the web a bug is a twenty minute deploy. In the stores it is a submission. For a company still changing its mind weekly, that is the expensive part.

A progressive web app installs to the home screen, works offline, and updates the moment you push. Start there and let real usage tell you whether you need the stores.

Editing everything is not the same as editing content

Can we edit it ourselves is the most reasonable request on the list, and behind it is nearly always a specific bad memory: a previous agency that charged for a typo and took four days to change a phone number.

You should have that independence. A client who cannot change their own copy stops updating the site, and a site that stops being updated stops earning. The trap is the word everything. Editing text, images, prices, team members and posts is a solved problem. Editing layout, adding arbitrary sections and rearranging the page means a page builder, and the page builder is what installs the ceiling.

There is a number for that ceiling. In the 2025 Web Almanac, WordPress sites passed Core Web Vitals 45% of the time against 74% for Wix, and the gap is attributed largely to accumulated plugins and builders rather than to the core software. If speed is a product requirement rather than a preference, the answer is a built site with defined editable regions, which is a smaller ask than it sounds.

The reference site you cannot copy

Make it look like Linear, or Stripe, or Vercel, or occasionally Apple. Always a company with a design team larger than the entire startup asking, and nearly always a developer tools or fintech product with a dark palette, enormous whitespace and one gradient.

The goal underneath is credibility, and that is a good goal. The problem is that the reference is the wrong instrument for it. Those sites are austere as a consequence of having one product, one audience, and a team to enforce it. Copy the surface onto a company with three offers and a services page and it stops reading as confidence and starts reading as a template.

The parts that transfer are cheap and unglamorous: restraint in the palette, one typeface used properly, real spacing, and content that says one thing per screen. The parts that do not transfer are the ones people point at, the ten second hero animation and the WebGL background, which on a startup site mostly cost you the first paint.

Five things nobody asks for

The rest of the list is the logo, three languages from day one, and can you put AI in it, each of which has a real answer and a longer explanation than fits here. More interesting is what never comes up at all.

Who writes the content is the first, and it is the single biggest reason projects run late. Design and build finish on schedule, then the site waits five weeks for the About page. A site with placeholder text cannot launch, so this is not a detail, it is the critical path, and it belongs in the kickoff rather than in an apologetic email in week six.

Measurement is the second. Founders ask whether the site will rank and almost never ask how they will know whether it worked. Without analytics in place on day one there is no baseline, so the redesign argument in month eight becomes a matter of opinion.

Accessibility is the third, and in the EU it is no longer optional. Since 28 June 2025 the European Accessibility Act has applied to a broad set of products and services sold to consumers, e-commerce included, with WCAG 2.2 as the practical reference. Built in from the start it costs very little. Retrofitted onto a finished site it is expensive.

The legal and privacy layer is the fourth, and it interacts badly with the second, because a consent banner bolted on in month six usually breaks the analytics nobody was checking anyway. What happens after launch is the fifth. A site is not a delivery, it is a thing that runs, and dependencies age whether or not anyone is watching.

If you only ask an agency one thing, ask what the smallest version is that would still tell you something. Not the cheapest, the smallest that produces a real signal. Anyone who cannot answer that, or who answers it by describing their largest package, has told you what kind of relationship this is going to be.

Read the full version

This is the condensed version. The full article counts all ten down properly, puts real prices on each one, and includes the arithmetic for what a first startup site actually costs at two different stages.

Ten things startups ask a web agency for

Sources

The failure statistics come from CB Insights' analysis of startup post-mortems. The Core Web Vitals comparison is from the 2025 Web Almanac CMS chapter, and the indexing timeline is stated by Google in its SEO starter guide. Store costs are published by Apple and Google Play. The accessibility deadline is Directive (EU) 2019/882, with WCAG 2.2 as the conformance reference. The ordering, the pricing and the opinions are mine.

If you take client work, I would be curious whether your enquiries land in the same order, and particularly whether the cheapest option question arrives as early for you as it does for me.

A website redesign above €5M revenue is not a design project. It is a migration with a committee attached.

Alex — Wed, 02 Sep 2026 22:47:03 +0000

Every redesign checklist on the internet is written for a company with one decision-maker. Pick a platform, agree a direction, build it, launch it. That checklist is fine, and it stops being fine somewhere around the point where the site is carrying real revenue.

What changes is not the design work. It is almost the same design work. What changes is that the site has become load-bearing — for organic pipeline, for integrations other teams depend on daily, for pages legal has opinions about — and a redesign of a load-bearing system is a migration, not a blank page. Most of the damage I have seen on projects this size came from treating it as the latter.

The number that explains the whole problem

Forrester's 2024 State of Business Buying research puts the average B2B purchase decision at 13 internal stakeholders, with nearly 89% of those decisions crossing more than one department.

A redesign at this revenue band is exactly that kind of decision, whether or not anyone has named it one. Nobody sends a memo announcing that the project now has a buying committee. It simply turns out, in week six, that the CMS choice needs IT sign-off, the cookie banner needs legal, and a regional office has been quietly assuming their pages are staying exactly as they are.

That is the actual difference between a €2M redesign and a €5M+ one. The production work is nearly identical. The wrapper around it is a different project.

Scope creep stops being annoying and starts being expensive

PMI's Pulse of the Profession research has repeatedly found scope creep affecting a large share of projects — 52% in its 2018 survey, up from 43% five years earlier. A redesign with a dozen stakeholders, each wanting one more thing, is the textbook case.

The instinct is to fix this with discipline during the project. That does not work, because the additions do not arrive as scope changes. They arrive as reasonable requests from people who were not in the scoping conversation and genuinely did not know it had happened.

The fix is earlier and duller: decide before kickoff who is allowed to add scope. Not who is consulted, not who is copied — who can actually add. In practice that is one person, and naming them is a ten-minute conversation that saves a month.

The same shape applies to approvals. A 2025 survey of 500 marketing and creative professionals found 74% say the approval process takes more effort than the creative work under review, and over 60% lose up to a full workday per week chasing approvals. On a five-approver project that does not divide, it compounds. One named approver per phase beats five people on a thread, every time.

Treat it as a migration and the technical list writes itself

Here is the part that is genuinely our problem as engineers rather than a governance abstraction.

If the current site earns organic traffic, that traffic is an asset with a specific failure mode, and preserving it is a deliverable with an owner — a redirect map, a pre-launch crawl, metadata that survives the platform change. It is not a task you discover in launch week. I wrote up the mechanics of that separately in redesigning a site without losing its SEO, because it is the single most common way a technically clean launch turns into a bad quarter.

Then inventory what else the site is quietly load-bearing for. A CRM or ERP integration a sales team uses daily. An analytics setup finance forecasts against. Compliance pages nobody wants to accidentally drop. The reliable way to get this list is to audit it, not to ask whoever has been at the company longest to remember.

And three decisions are disproportionately expensive to reverse once the build starts: the platform choice, settled with IT in the room rather than discovered mid-build; the regional and language architecture, decided as structure before a single template exists, because retrofitting multilingual onto a single-language build is close to a second project; and accessibility, which is now a dated legal obligation across the EU rather than a nice-to-have.

Capture the baseline, or lose the argument you have not had yet

This is the cheapest item on the list and the most frequently skipped.

A redesign at this size will be judged after launch, by people who were not in the room for the decisions, against numbers nobody wrote down beforehand. So write them down: organic sessions and conversions for the top fifty landing pages, conversion rate per template, average lead or order value, and current Core Web Vitals field data.

Export it. Do not trust that the analytics property will still be comparable — a replatform frequently changes tracking, and a baseline you cannot reproduce after launch is not a baseline.

The reason is not reporting hygiene. Every migration has a re-crawl dip. Without a recorded starting point, three weeks of entirely normal fluctuation reads to a committee as proof the project failed, and the reaction to that — reverting design decisions, second-guessing the redirect map — does far more damage than the dip. With a baseline, the same three weeks is a line on a chart visibly returning to where it started.

The second workstream nobody estimates

At this size the project acquires a parallel track that has nothing to do with design and is almost never in the original estimate. A vendor security questionnaire from IT. A data processing agreement and a records-of-processing update, particularly where forms, analytics or a CRM integration change. Cookie consent legal actually signs off on rather than a banner installed on launch day. Procurement onboarding, which at some companies is weeks before an invoice can be raised.

Accessibility belongs here too, and it is dated: the European Accessibility Act has applied across all 27 member states since 28 June 2025. The most commonly missing piece on sites that otherwise meet the requirements is the published accessibility statement — which is a document, not code, and therefore nobody's ticket.

None of this work is hard. All of it consumes calendar time from people who do not report to the project. That is precisely why it belongs in the plan at kickoff instead of being discovered in launch week.

What this does to the timeline

The production work stretches far less than people assume. A multi-page rebuild still runs roughly the same six-to-fourteen-week window as any business site, and even a genuinely custom platform with heavy integrations is realistically six months of build, not years.

What stretches is the governance wrapped around it. If production is six to fourteen weeks and every phase needs sign-off from a five-person committee with its own meeting cadence, four to nine months end to end is the honest band — not because the work takes that long, but because the approval layer does.

Saying that number out loud at kickoff is uncomfortable and it is the single most useful thing you can do for the project. The alternative is a fourteen-week estimate that everyone stops believing in month three, at which point every subsequent conversation is about the schedule rather than the work.

The short version

Name the approvers before design starts, one per phase. Decide who can add scope, and make it one person. Treat the existing site as a system to migrate rather than a page to replace, and inventory what depends on it. Export the baseline before anything changes. Put the security questionnaire, the DPA, the consent review and the accessibility statement in the plan at kickoff, where they cost days instead of weeks.

None of that is design advice, which is the point. Above a certain revenue, the design was never the risky part.

Read the full version

This is the condensed version. The full article has the side-by-side of what changes above and below €5M, the specific five-approver list, the platform and multilingual decisions in more detail, and the questions clients actually ask — including what counts as "enterprise" in the first place.

The website redesign checklist for companies over €5M revenue

Sources

The stakeholder figures are from Forrester's The State Of Business Buying, 2024. The scope-creep numbers come from PMI's Pulse of the Profession 2018. The approval-time figures are from a 2025 survey of 500 US marketing and creative professionals. The accessibility deadline is Directive (EU) 2019/882, applicable since 28 June 2025. The revenue-band framing and the checklist itself are mine, from client projects.

If you have run one of these on the engineering side, I would be curious which item on your list turned out to be the expensive one — my money is on the integration inventory, but the baseline export is the one people regret skipping.

GEO is not the new SEO. It is a licensing decision with a formatting problem attached.

Alex — Wed, 02 Sep 2026 01:19:00 +0000

Every few months a discipline arrives with an acronym and a price list attached, and the honest question is whether there is anything underneath it. GEO — generative engine optimization, sometimes AEO — is unusual in that there genuinely is. It comes from a 2023 research paper rather than an agency deck, the paper built a benchmark, and it measured how much the techniques actually move the needle.

The measurement is the part that gets left out of the pitch, because it is not the number a pitch wants.

Where the term comes from, and what it measured

Aggarwal et al. introduced both the term and GEO-bench, a benchmark of diverse user queries paired with source documents, and demonstrated visibility improvements of up to roughly 40% inside generated answers. That is a real, replicated, published result and it is worth taking seriously.

It is also bounded in a way the marketing around it rarely reproduces. Forty per cent more visibility within a generated answer is not a rewrite of who gets recommended in your market. It is an improvement in how likely your existing page is to be selected and quoted, applied to a page that was already a plausible candidate. Nothing in the paper suggests you can format your way from invisible to authoritative.

The second finding matters more and is quoted even less: which technique works varies significantly by domain. The tactic that lifts a technical comparison page is not the tactic that lifts a local service page. Anyone selling you a single universal GEO playbook either has not read the paper or is hoping you have not.

What it actually shares with SEO, which is most of it

The technical fundamentals do not change at all. Fast pages, clean semantic HTML, a proper heading structure, schema markup — these help a classic crawler and a retrieval system for the same reason, which is that both need to work out what a page says and whether to trust it.

Google is unusually direct about this in its own documentation: AI Overviews and AI Mode draw on the same index and the same quality systems as classic Search, and there is no separate AI submission process. There is no second index to get into. If the page is not indexed and eligible to be shown with a snippet, no amount of GEO work reaches it.

So the useful framing is additive, not alternative. If your SEO foundation is weak, GEO does not route around it — it inherits the weakness. Most of the "we are not being cited anywhere" cases I have looked at were not content problems at all. They were a page that renders nothing without JavaScript, or a bot rule in a CDN that somebody switched on eighteen months ago and nobody remembers.

What GEO genuinely adds on top

Structured data becomes more directly consequential than it is in classic SEO. FAQ, HowTo, and clear Organization and Article markup give a retrieval system an unambiguous way to extract a fact rather than infer one. Schema.org is the shared vocabulary underneath all of it, and it is the least glamorous, most reliably useful work in this entire area.

Content that answers one specific, narrow question outperforms broad pages, and the mechanism is worth understanding rather than just obeying. These systems are lifting a passage. A page with a direct answer near the top of each section gives them something clean to lift; a page that spends three paragraphs warming up gives them a choice between quoting the preamble and quoting nobody. Structure is doing real work here, not cosmetic work.

Then there is the half you cannot edit. Being mentioned elsewhere — press, directories, industry roundups, comparison pieces — feeds retrieval in a way that is harder to measure than a backlink and is nonetheless real. Consistency matters here more than volume: answer engines cross-reference sources rather than trusting one, so a business described three different ways in three places gets attributed less confidently than one described identically everywhere. That is an unglamorous afternoon of work on your directory listings, and it beats another rewrite of your homepage.

The ceiling nobody puts in the proposal

Here is the number that should shape the budget conversation. Pew Research Center ran a panel study of 68,879 searches and found that when an AI summary is present, 8% of visits result in a click on a traditional result, against 15% when no summary appears. Clicks on a link inside the summary itself: 1%.

Read that carefully, because it cuts both ways and both directions are real.

The pessimistic reading is that being cited is worth far less traffic than being ranked used to be. A citation is not a visit. If your entire model depends on click volume from informational queries, AI summaries are a structural problem that no amount of GEO fixes, because the technique optimises for being chosen inside a box that people mostly do not click.

The optimistic reading is that the clicks are collapsing whether or not you participate. If summaries appear on your queries, the traffic is going regardless, and the choice is between being the cited source inside the answer and not being mentioned at all. Being named in the answer a buyer reads has value that does not show up in your analytics — which is uncomfortable to budget for and still true.

What I would not do is let anyone sell GEO to you on traffic projections. The mechanism it improves is citation, and citation converts to sessions at roughly 1%.

The prerequisite that rarely gets mentioned

Before any of the formatting work matters, the engines have to be allowed to use you, and that is a separate decision from being crawled.

Google splits it with a robots.txt token called Google-Extended. It is not a crawler — Googlebot still does the fetching. It governs whether what was fetched may be used to train future Gemini models and for grounding. And Google's own wording on the consequence is unusually unambiguous: Google-Extended "does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search."

That single sentence turns this into a licensing decision rather than an SEO one, which is a much better decision to be making. You can stay fully indexed and fully ranked while opting out of the generative uses. It is a real choice, not a trap with a ranking penalty hidden in it.

Which way to go depends on what you sell. If being cited inside AI answers is the point — you want the mention, the traffic was never the model — leave it open. If your writing is the product, closing it costs you nothing in rankings, and that is worth knowing before someone tells you that blocking AI crawlers will hurt your SEO. Through this token, it will not.

The one thing it will not do is speak for anyone else. Every operator publishes its own token and honours its own rules, so Google's covers Google. Treating AI access as a single on/off switch is the most common mistake in this area. In practice it is a short list of separate decisions, one per operator, and it belongs in a policy document rather than in a robots.txt file somebody edits from memory.

How to tell whether any of it is working

This is the honest weak point, and pretending otherwise is how this field loses credibility. Measurement tooling for AI citation is immature next to classic search analytics.

The most reliable method available right now is unglamorous: take your actual target queries, run them against ChatGPT, Perplexity and Google AI Overviews, and record whether you are cited. Alongside that, watch your analytics for referral traffic from AI platforms, knowing it will undercount.

One warning that costs people real money. Do not measure this with a single check. These systems regenerate their answers constantly, and a screenshot taken on a Tuesday is closer to a coin flip than to a data point. Run a fixed prompt list repeatedly across several days and report the share of runs in which you appear — and freeze that list early, because changing it mid-measurement destroys the comparison. I wrote up the volatility data behind that advice separately, in How long until ChatGPT and Perplexity actually cite you?, if you want the numbers rather than the rule.

What I would actually do

Fix what the crawlers see first, because it is the cheapest work and the most common cause of failure. Then make your structure liftable: a direct answer near the top of each section, real headings, schema that states plainly who you are and what you sell. Then go and make your facts consistent everywhere else on the web, which is the part nobody enjoys and the part that compounds.

Then decide the licensing question deliberately, per operator, and write down why.

And set expectations on the way in: bounded gains, domain-dependent tactics, a 1% click-through on the citation itself, and measurement you have to build yourself. Everything in that sentence is from published research or the platforms' own documentation, and every one of them is a thing a GEO pitch tends to leave out.

Read the full version

This is the condensed version. The full article covers the SEO-versus-GEO overlap in more detail, the schema types worth implementing first, and the questions clients actually ask — including whether anyone can guarantee a citation.

Generative Engine Optimization (GEO) Explained

Sources

The definition and the measured gains come from Aggarwal et al., GEO: Generative Engine Optimization (arXiv:2311.09735). The click-through figures are from the Pew Research Center panel study of 68,879 searches. The platform behaviour is documented by Google directly, in AI features and your website and Google crawlers and user-triggered fetchers, and the structured-data vocabulary is Schema.org. The read on what all this means for a smaller site is mine.

If you have been running a fixed prompt list against these engines for any length of time, I would like to know how stable your results have been — particularly whether the Google-Extended decision changed anything measurable for you either way.

Do you still need Figma designs before development?

Alex — Tue, 01 Sep 2026 02:43:46 +0000

The design phase used to be unarguable. You could not build a website without deciding what it looked like first, and deciding on a canvas was cheaper than deciding in code.

Both halves of that are now under pressure. Tools generate working interfaces directly from a prompt, and Figma itself is dissolving the boundary between the design file and the codebase. So the question a client asks in the kickoff call — "do we actually need this step?" — is a fair one, and answering it with "yes, obviously" is no longer good enough.

The honest answer is that some projects should skip it entirely and some projects will pay three times over for skipping it. What separates them is not budget or ambition. It is how many decisions the project contains.

The file is not a picture of the website

This is the misunderstanding underneath most of the argument. A Figma file looks like a deliverable, so it gets priced and judged like one: here is a picture, here is the invoice, why is a picture this expensive.

It is a decision document. It is the place where layout, hierarchy, spacing, states, responsive behaviour and edge cases get settled while changing your mind is still nearly free. The visual output is a side effect of that process, which is why "we can just see it once it's built" tends to cost more than it saves.

The economics hold up in practice and they are not subtle. Moving a section on a canvas takes minutes. Moving it in built code takes hours, touches tests, and sometimes invalidates a round of QA that already passed. The design phase is not there to produce artwork. It is there to concentrate the expensive changes into the cheap part of the project.

Which means the real question is never "design or no design". It is: where do you want to be wrong?

What genuinely changed in 2026

Enough that the old defence of the design phase needs updating rather than repeating.

At Config 2026 in June, Figma shipped Motion with animation export in Dev Mode, expanded its canvas design agent with MCP connectors, and previewed code layers living on the design file itself. Combined with the Dev Mode MCP server, which feeds structured design context — variables, components, layout — straight into a developer's AI tooling instead of a screenshot and a guess, the handoff is measurably less lossy than it was two years ago.

The practical effect is that the file stops being a one-way deliverable thrown over a wall and becomes a shared reference that stays accurate. Animation specs no longer die in a Slack thread. A token change in the design system does not require a translation meeting.

Read that carefully, though, because the conclusion people jump to is the wrong one. Better handoff makes the design phase cheaper. It does not make it unnecessary. The tooling improved at transmitting decisions; it did not start making them.

When you can genuinely skip the mockups

I would rather say this plainly than pretend every project needs the full process, because the padded version of this step is a real thing and clients are right to be suspicious of it.

Skip it when the scope is small and the pattern is established. A single landing page following a layout that has already proven itself. A page built from an existing design system. A template-based build where the design decisions were effectively made at the moment the template was chosen. In all three, designing first duplicates work that someone has already done, and you are paying for the duplicate.

Skip it for internal tools, prototypes, and anything you intend to throw away. If the audience is three colleagues and the lifespan is a quarter, build it and iterate on the real thing. Paying for a polished design of something disposable is the actual waste in this industry, and it happens more often than skipping design does.

When skipping it costs more than it saves

Multiple pages that have to feel like one site. Coherence is not a per-page property, and it is the first thing to disappear when every screen is invented at build time.

Anything with a review chain. Two stakeholders with different opinions will find each other eventually, and finding each other on a canvas costs a comment thread while finding each other in staging costs a sprint. This is the one people underestimate most consistently, because the disagreement is invisible at kickoff.

Custom interfaces without an obvious precedent: configurators, dashboards, multi-step flows, anything where interaction states outnumber screens. If a page has one appearance you can build it and look at it. If it has eleven, you need somewhere cheap to see all eleven at once.

And any project where the site is the main commercial channel. If layout determines revenue, it deserves a round of deliberate thinking before it becomes a build.

The middle path, which is what most projects actually want

Design the two or three hardest screens properly. Define the system underneath them — type scale, spacing, colour, component states, breakpoints. Build everything else directly from that system.

You get the benefit of decided design without paying to draw every page, and the developer is never guessing what a hover state or an error message should look like. Nielsen Norman Group's distinction is worth internalising here: a component library is not a style guide is not a design system, and the thing that removes rework at handoff is specifically the documented, shared source of truth — not the pile of components.

This is also, and I think this is the underrated part, what makes AI-assisted building actually work. Given real tokens and two reference screens, generated output is coherent and genuinely fast. Given a prompt and no system, it produces plausible screens that do not belong to the same website — each one defensible alone, collectively obviously assembled. The design system is the constraint that makes the speed safe. Skipping design does not make AI generation faster; it makes its output unusable at the point where you try to combine it.

The constraint nobody designs for until it bites

If the site will ever ship in more than one language, the mockup you are approving is not the design. It is the shortest of three.

W3C's internationalization guidance, citing IBM's figures, is that a source string of ten characters or fewer can expand by 200–300% once translated, and one of eleven to twenty characters by 180–200%. Only long passages behave, settling around 130%. German is the usual culprit: "views" becomes "-mal angesehen", roughly 2.8 times the length.

That is a design constraint, not a translation problem, and it lands hardest exactly where designs are tightest — nav items, button labels, tabs, card headings, table columns. A label that fits the English artboard to the pixel will wrap onto a second line, clip, or shove its neighbour out of alignment in another locale, and it will do it after the templates are built and approved.

The cheap version of this is laying out the tightest components with the longest locale in the box, or at absolute minimum pasting the three worst strings in before sign-off. The expensive version is finding out on launch day for the second market, which is how a content job turns into a redesign.

Same category, same timing: WCAG's 4.5:1 and 3:1 contrast ratios are among the cheapest things to check while a design is still a file, and among the most expensive to retrofit once a brand palette is threaded through built components.

What to ask, if you are the one paying

Three questions, and the answers tell you more than the portfolio does.

Ask what happens to the design file after launch. If it is abandoned, you paid for a deliverable rather than a system, and the next change starts from zero.

Ask whether the design defines states and breakpoints or only desktop screens. Everything left undefined becomes a developer's guess, made at speed, under deadline, without you in the room.

And ask what you can cut. A competent team should be able to name the parts of the design phase your specific project does not need. If the answer is "all of it is essential" on a five-page site, that is information too.

Read the full version

This is the condensed version. The full article covers how much of a budget design should realistically be, what to do when an agency owns your design file, whether designing straight in the browser is a legitimate approach, and the rest of the questions clients actually ask before signing.

Do you still need Figma designs before development?

Sources

Tooling changes are from Figma directly — the Config 2026 recap and the Dev Mode MCP server announcement. The design-system distinction is Nielsen Norman Group's Design Systems 101. The expansion figures come from W3C's Text size in translation, and the contrast ratios from WCAG 2.2 Success Criterion 1.4.3. Where to draw the line is mine, from projects that went both ways.

If you have shipped something recently with no design phase at all, I would like to know what it cost you later — or whether it genuinely cost nothing, which does happen and is worth hearing about.

Google cites new pages in a day. ChatGPT takes weeks.

Alex — Mon, 31 Aug 2026 15:46:53 +0000

Every guide to generative engine optimization explains what to do. Almost none of them say when it pays off, which is the only question anyone actually asks before committing budget to it.

That gap existed for a good reason. Answering it properly needs something nobody had bothered to build: a set of pages published at a known moment and then checked against several answer engines every single day afterwards. Without that, every claimed timeline was somebody's impression of their own client work, and impressions are exactly the wrong instrument for a system that regenerates its answers every couple of days.

The measurement now exists. Eighty-one newly published pages on a single domain, queried daily for thirty days across Google's AI Mode and ChatGPT search. Here is what it found.

Google moves in days. ChatGPT moves in weeks.

The gap at the start is larger than most people expect. Within 24 hours of publishing, 36% of the test pages were already being cited somewhere in Google AI Mode. ChatGPT search had picked up 10% in the same window, more than three times slower off the line. By day seven, Google was at 56% and ChatGPT at 17%.

Then the curves change character, and this is the part that matters. Google's coverage fluctuated week to week, rising toward a peak of 59% and falling back from it repeatedly. ChatGPT's climbed steadily and did not give ground: 35% at two weeks, 42% at thirty days. Google is fast and noisy. ChatGPT is slow and cumulative.

That has a direct consequence for how you report on this work, and it is where people get burned. A project reviewed at four weeks looks like a Google success and a ChatGPT failure, and both readings are artefacts of the review date rather than facts about the work. The correct checkpoint is somewhere past six weeks, and the correct framing is two separate curves rather than an average that describes neither.

Perplexity sits outside the comparison for a structural reason. A significant share of its crawling is triggered by a user's question rather than by a schedule, so on a narrow, specific prompt it can be the fastest of the three, and on a broad one it can lag both.

The clock starts at crawl, not at publish

The first week is not a content problem, and treating it as one wastes it. OpenAI runs three separate bots and the distinction matters: OAI-SearchBot surfaces sites in ChatGPT's search features, GPTBot crawls for model training, and both obey robots.txt, while ChatGPT-User fetches a page live because a person asked a question and is explicitly not bound by the same rules. Perplexity splits the same way, with PerplexityBot building the index under robots.txt and Perplexity-User fetching live during a question.

Both operators quote roughly the same latency on the control side, about 24 hours from a robots.txt update for their systems to adjust. That is a small number with a sharp edge, because an accidental block costs a day to undo after somebody notices. And the most common cause is not robots.txt at all. It is a bot-protection rule in a CDN that nobody remembers switching on.

Google is a different case entirely, and simpler. Its own documentation states there are no additional requirements to appear in AI Overviews or AI Mode and no special markup necessary, but that to be used as a supporting link a page must be indexed and eligible to be shown in Google Search with a snippet. The AI clock and the classic indexing clock are the same clock. There is no separate AI index to get into, and if the page is not indexed, no amount of GEO work reaches it.

So before blaming your content, check whether the crawlers are in your server logs at all, whether a firewall rule is turning them away, whether the page is indexed, and whether it renders anything useful without JavaScript. A crawler that receives an empty shell has technically fetched you and learned nothing. Those four cover most cases of "we are not being cited anywhere".

The ceiling nobody quotes

The number worth carrying out of this is not a speed, it is a limit. Over a full month, Google AI Mode peaked at 59% of the test pages and ChatGPT search reached 42%. That was on a domain with strong established authority publishing squarely inside its own subject area. Even under those conditions, roughly half of everything published was never cited anywhere.

This is the honest correction to how GEO is usually sold. The pitch implies that structuring content correctly makes it citable. The data says structuring content correctly makes it eligible, and selection is a separate, competitive step you do not control.

Plan on that basis and the economics stay sane. A page that fails to get cited is not a failed page, it is the expected outcome for about half of them, and the ones that do get cited tend to keep the citation. The practical consequence is that publishing a small number of genuinely specific answer pages beats publishing many broad ones, because the ceiling is per-page and broad pages lose to bigger entities every time.

A single check tells you almost nothing

This is the least intuitive finding in the area and it should change how you measure. Ahrefs tracked more than 43,000 keywords with at least sixteen recorded AI Overviews each and found an average persistence of 2.15 days, meaning an AI Overview has roughly a 70% chance of being different from one observation to the next. More usefully, only 54.5% of the cited URLs overlap between consecutive runs of the same query. Close to half the source list is replaced every time.

What does not change is the meaning. The same query re-run produces answers with an average cosine similarity of 0.95, and 54% of the named entities stay put. The system is confident about what it thinks and casual about who it credits, which means a citation appearing or disappearing on any given day carries far less signal than it feels like it does.

The rule follows immediately. Never measure AI visibility with a single check. Run a fixed prompt list at least ten times across several days and report the share of runs in which you appear, and freeze that list early, because changing it mid-measurement destroys the comparison and is how most in-house tracking quietly dies. A binary "are we cited" screenshot is roughly a coin flip, and I have watched more than one agency relationship turn on one taken at the wrong moment.

Ranking still helps, but a lot less than it did

For most of the AI-search era the reassuring answer to "how do we get cited" was "rank well, the rest follows". In July 2025 that held up, when Ahrefs analysed 1.9 million citations from a million AI Overviews and found 76.1% of cited pages ranked in Google's top 10.

By March 2026 the same analysis over 863,000 SERPs and four million AI Overview URLs put the top-10 share at 37.9%, with 31.0% coming from pages beyond the first hundred results entirely. Ahrefs attribute the shift to Google changing the model behind AI Overviews in January 2026 and expanding its query fan-out more aggressively, pulling sources from related searches rather than only the one the user typed.

Two things follow, and they pull in opposite directions on purpose. Ranking is no longer a reliable route to citation, so a strong SEO position is not the guarantee it was. But not ranking is no longer disqualifying either, and roughly a third of citations now coming from pages nobody would find in a normal search is the first genuinely new opportunity this field has produced for smaller sites.

What to do while you wait

The waiting period is not idle time, and the work that pays during it is unglamorous. Fix what the crawlers see: server-rendered content, clean headings, a direct answer near the top of each section rather than three paragraphs in, and structured data that states plainly who you are and what you sell. None of that is AI-specific. It is the same technical foundation classic search rewards, which is why the two disciplines are additive rather than alternatives.

Then work on the half you cannot edit. Answer engines cross-reference sources rather than trusting one, so the same facts about your business appearing consistently across directories, profiles and comparisons does more for attribution than another rewrite of your homepage. A business described three different ways in three places gets attributed less confidently than one described identically everywhere.

The caveats, stated plainly

The day-by-day figures come from one controlled test on one domain with strong existing authority. Treat them as a best case rather than an average, because a newer or weaker site should expect the same shape stretched over a longer axis and a lower ceiling.

There is also no submission form, no priority queue and no paid inclusion route anywhere across these engines. The only levers are being crawlable by the right agents, being indexed where indexing is the gate, and being a page worth selecting over the alternatives. Anyone offering to fast-track you is selling something that does not exist.

And the honest one: Google changed the model behind AI Overviews in January 2026 and the ranking-to-citation relationship roughly halved within months. Any timeline in this field, including this one, describes a moving system rather than a law. What has stayed stable across every change so far is only the shape. Google is fast and volatile, ChatGPT is slow and cumulative, and about half of what you publish is never cited at all.

Read the full version

This is the condensed version. The full article walks the first six months week by week, covers what each engine specifically needs before it can cite you, and answers the parts I skipped here, including whether you should be blocking AI crawlers at all.

How long until ChatGPT and Perplexity actually cite you?

Sources

The citation timings come from Semrush's controlled test of 81 newly published pages. The volatility figures are from Ahrefs on how often AI Overviews change, and the ranking comparison from their July 2025 analysis and its March 2026 re-run. Crawler behaviour is documented by OpenAI, Perplexity and Google directly. The measurement advice and the read on what all this means for a smaller site are mine.

If you have been tracking your own citation timings I would genuinely like to hear how they compare, particularly from anyone on a newer domain, since that is exactly the case the published study does not cover.