Roastidio.us Tagged with web

A Linux-like kernel in a browser tab - deep dive in the BrowserPod architecture

Mon, 18 May 2026 17:06:25 +0000

Cross-Document View Transitions: The Gotchas Nobody Mentions | CSS-Tricks

Mon, 18 May 2026 17:06:25 +0000

I wasted an entire Saturday on this.

Not a lazy Saturday either, but one of those rare, carved-out, “I’m finally going to build that thing” Saturdays. I’d seen Jake Archibald’s demos. I’d watched the Chrome Dev Summit talk. I knew cross-document view transitions were real, that you could get those slick native-feeling page transitions on plain old multi-page sites without a single framework. No React. No Astro. No client-side router pretending your multi-page application (MPA) is single-page application (SPA). Just HTML pages linking to other HTML pages, with the browser handling the animation between them. Hell yes.

So I started building. And nothing worked.

The first tutorial I found had me dropping <meta name="view-transition" content="same-origin"> into my <head>. Seemed simple enough. I added it to both pages, clicked my link, and… nothing. No transition. No error. Just a normal, instant page load like it was 2004. I opened DevTools, double-checked my syntax, restarted the server, tried Chrome Canary, cleared the cache. Nothing. I did what any self-respecting developer does at that point – I copied the code character by character from the blog post and pasted it in. Still nothing.

I spent two hours convinced I was an idiot.

Turns out that <meta> tag syntax? Deprecated. Gone. Chrome shipped it, then replaced it with a CSS-based opt-in, and half the internet’s tutorials still show the old way. Those older blog posts still rank well. They look authoritative. And they’re just wrong now. Not wrong because the authors were bad – wrong because the spec moved under everyone’s feet and nobody went back to update their posts.

The other half of the tutorials I found were about same-document view transitions. SPA stuff. document.startViewTransition() called in JavaScript when you swap DOM content yourself, which is cool and useful but a completely different feature when you actually sit down to implement it. The API surface is different. The mental model is different. The gotchas are very different. And yet, Google “view transitions tutorial” and good luck figuring out which flavor you’re reading about until you’re three paragraphs deep.

So if you’re here, I’m guessing you’ve been through some version of this. You tried the meta tag. It didn’t work. You tried the JavaScript API on a real multi-page site and realized it only fires within a single document. You maybe got something half-working in a demo but it fell apart the second you added real content â€” images stretching weird, transitions hanging for seconds with no explanation, or your CSS file turning into 200 lines of view-transition-name declarations because you have a grid of 40 product cards. You blamed yourself. It wasn’t your fault. The documentation ecosystem around this feature is a mess right now, and the spec has been a moving target.

This is Part 1 of a two-part series, and it’s the article I wish existed on that Saturday. We’re going to cover the actual current way to opt in with @view-transition in CSS (not the meta tag, not JavaScript), then dig into the 4-second timeout that will silently kill your transitions on slow pages and how to debug it, then fix the aspect ratio warping that makes every image-heavy transition look like a fun house mirror, and finally get a proper handle on the pagereveal and pageswap events that give you programmatic control over the whole lifecycle.

In Part 2, we’ll tackle the scaling problem – how to handle view-transition-name across dozens or hundreds of elements without your stylesheet becoming a disaster, the difference between view-transition-name and view-transition-class, just-in-time naming patterns, and doing prefers-reduced-motion the right way.

Cross-Document View Transitions Series

The Gotchas Nobody Mentions (You are here!)
Scaling View Transitions Across Hundreds of Elements (Next Monday!)

Grab coffee. Maybe a refill. This one’s dense and I’m not going to waste your time, but there’s a lot of ground here and none of it is obvious.

The Old Way is Dead

<!-- THIS IS DEPRECATED - stop copying this from old tutorials -->
<meta name="view-transition" content="same-origin">

/* THIS is the current opt-in - goes in your CSS */
@view-transition {
  navigation: auto;
}

Here’s the minimal setup. Two HTML files, one CSS rule on each. Note that, as of 2026, cross-document view transitions are supported in Chromium-based browsers and Safari 18.2+. Firefox support is in progress as I’m writing this.

That’s it. Two HTML files. One CSS rule on each. Click a link between them in a supporting browser (like modern Chromium or Safari 18.2+) and you get a smooth cross-fade. No JavaScript. No meta tags. No build step. The browser snapshots the old page, snapshots the new page, and animates between them automatically.

Now, why did the spec move from a meta tag to a CSS at-rule? It wasn’t arbitrary.

The meta tag was a blunt instrument. It was on or off for the entire page. You couldn’t say “enable transitions on desktop but not on mobile where the animations feel janky on low-end hardware.” You couldn’t conditionally opt in based on user preferences. It was just… there, or not.

The CSS approach opens all of that up:

/* Only enable transitions if the user hasn't asked for reduced motion */
@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

/* Only enable on viewports wide enough for the animation to feel good */
@media (min-width: 768px) {
  @view-transition {
    navigation: auto;
  }
}

That’s a real upgrade. You get the same conditional power you already have with every other CSS feature. Media queries, @supports, whatever scoping logic you want — it all just works because the opt-in lives where your styles live.

There’s also a subtlety that matters: the CSS rule can be different on the old page versus the new page. Both pages need to opt in for the transition to fire. If Page A has @view-transition { navigation: auto; } but Page B doesn’t, you get no transition. This is actually useful – it means your 404 page or your login redirect can skip transitions without any JavaScript coordination.

One more thing worth noting here: navigation: auto only kicks in for user-initiated, same-origin navigations. If the user clicks a regular link or hits the browser’s Back button, you get a transition. But window.location.href = "/somewhere" set programmatically, or a cross-origin link, or a form submission with a POST? No transition. The browser is intentionally conservative about when it fires, and honestly that’s the right call. You don’t want a fancy cross-fade on a POST request that’s creating a payment.

Look, if you’ve been following an outdated tutorial and your transitions just silently don’t work, this is almost certainly why. The meta tag shipped in Chrome 111, got a few months of real-world use, and then the Chrome team deprecated it in favor of the CSS at-rule starting around Chrome 126. No console warning. No error. The old syntax just quietly does nothing now. Honestly, a deprecation warning in DevTools would’ve saved me (and probably you) a lot of grief, but here we are.

Swap the meta tag for the CSS rule. That’s step one. Everything else in this article builds on it.

Your Transition Will Randomly Die, and Here’s Why

// Drop this in your pages to see what's actually happening
window.addEventListener("pagereveal", (event) => {
  if (!event.viewTransition) {
    console.log(
      "No view transition - page didn't opt in or browser skipped it",
    );
    return;
  } // This is the one that'll save your sanity

  event.viewTransition.finished
    .then(() => console.log("Transition completed ✅"))
    .catch((err) => {
      // You'll see "TimeoutError" here and nowhere else
      console.error("Transition killed:", err.name, err.message);
    });
});

Here’s the thing nobody puts in their blog post: cross-document view transitions have a hard 4-second timeout. If the new page doesn’t reach a state the browser considers “renderable” within 4 seconds of the navigation starting, the transition just… dies. No animation. No cross-fade. The new page snaps in like view transitions don’t exist. And unless you’ve got that pagereveal listener wired up and your console open, you won’t get any indication that anything went wrong.

Four seconds sounds generous â€” until it isn’t.

Think about what happens on a real site. Your page loads. The HTML arrives, fine, that’s fast. But maybe you’ve got a big hero image that’s render-blocking. Maybe there’s a slow API call that your server waits on before sending the response – a product page hitting an inventory service, a dashboard waiting on analytics data, anything with server-side rendering that actually does work before responding. Maybe you’re on a decent connection but the page has three web fonts loading from Google Fonts with font-display: block. Any of these can push you past that 4-second window, and the timeout doesn’t care why you’re slow. It just cuts the transition.

The really maddening part? It works perfectly on localhost. Your dev server responds in 80ms. The transition is butter. You deploy to production, your server’s cold-starting a lambda or your CDN cache missed, and suddenly users get zero transitions on the first click. You can’t reproduce it locally. You start questioning everything.

// You can also catch this on the OLD page using `pageswap`
// Useful for cleanup or logging which navigations fail
window.addEventListener("pageswap", (event) => {
  if (event.viewTransition) {
    event.viewTransition.finished.catch((err) => {
      // Log it, send it to your analytics, whatever
      console.warn("Outgoing transition aborted:", err.name);
    });
  }
});

So, what do you actually do about it?

Option one: make your page faster. I know, groundbreaking advice. But seriously – if your cross-document transition is dying, that’s a signal your page load is genuinely slow. The timeout is acting as a performance canary. Look at your Performance tab in DevTools, run a Lighthouse audit (which may not be perfect), figure out what’s blocking first render. This isn’t view-transition-specific advice, but the timeout forces you to care about it.

Option two is more interesting, and it’s the thing I wish I’d known about immediately.

<!-- Note: rel="expect" is newer and browser support is rolling out -->
<link rel="expect" href="#hero" blocking="render">

This:

<link rel="expect" href="#hero" blocking="render">

…tells the browser: “Don’t consider this page renderable until an element matching #hero is in the DOM.” That sounds like it would make things slower, and in a way it does – it delays first paint. But for view transitions, that’s exactly what you want: you’re telling the browser to hold the snapshot until the important content is actually there, rather than snapping a screenshot of a half-loaded page or, worse, timing out because some image in the footer is still downloading and blocking something.

It’s a trade-off. You’re choosing a slightly delayed, but smooth, transition over a fast, but-broken, one.

Honestly, the 4-second limit is probably the right call from the browser’s perspective. You don’t want a user clicking a link and staring at a frozen page for 10 seconds while the browser waits to do a fancy animation. At some point, just showing the damn page is better than a pretty transition. But I wish Chrome would surface the timeout more visibly – a DevTools warning, a performance marker, something. Right now it fails silently and that’s the whole problem.

One more thing worth knowing: the timeout clock starts when navigation begins, not when the new page’s HTML starts arriving. Network latency counts. The Time to First Byte (TTFB) Core Web Vital counts. If your server takes 2 seconds to respond and your page takes 2.5 seconds to render after that, you’re over the limit even though neither half feels slow on its own.

A debugging tip that’s saved me more than once: Chrome’s DevTools has an Animations panel (it’s under “More tools” if you don’t see it) that can actually capture view transitions in action. You can slow them down to 10% speed, replay them, and inspect the pseudo-element tree mid-animation. It’s not obvious that it works for view transitions, but it does. Between that and the pagereveal listener above, you can diagnose most timeout issues pretty quickly.

Put that pagereveal listener in early. Watch your console during testing. You’ll thank yourself later.

Why Your Images Look Like Taffy

This one’s easier to show with a same-document demo first (since you can actually run it in a single file), but the problem and the fix are identical for cross-document transitions.

Run that. Click the image. Watch the dog turn into silly putty.

The image itself has object-fit: cover on both sides. The thumbnail looks fine, the hero looks fine. But during the transition? The browser doesn’t transition your <img> element. It takes a screenshot of the old state, takes a screenshot of the new state, and morphs between them. Those screenshots are flat raster images. Your carefully applied object-fit? Gone. The browser is just scaling a bitmap from one box size to another, and when a 150Ã—150 square gets stretched into a 600Ã—300 rectangle, you get taffy.

Here’s the fix:

/* THE FIX - target the transition pseudo-elements directly */
::view-transition-old(hero-img),
::view-transition-new(hero-img) {
  /* Treat the snapshot like an image in a container - crop, don't stretch */
  object-fit: cover;
  overflow: hidden;
}

That’s the whole thing. Two properties on two pseudo-elements.

What’s actually happening: the browser generates a tree of pseudo-elements for every named transition. For an element with view-transition-name: hero-img, you get this structure during the animation:

::view-transition
└── ::view-transition-group(hero-img)
    ├── ::view-transition-old(hero-img)
    └── ::view-transition-new(hero-img)

The ::view-transition-group smoothly animates its width and height from the old dimensions to the new ones. That’s the morphing rectangle you see. Inside it, the old and new pseudo-elements hold the actual bitmap snapshots, and by default they’re set to object-fit: fill – meaning “stretch to fill whatever box you’re in, aspect ratio be damned.”

Switching to object-fit: cover tells those snapshots to maintain their aspect ratio and crop the overflow instead. Same mental model as a background image with background-size: cover. The transition still animates the box from square to rectangle (or whatever your shapes are), but the image inside crops gracefully instead of warping.

You could also use object-fit: contain here if you’d rather see the full image with letterboxing instead of cropping. It depends on what looks right for your content. But cover is what you’ll want 90% of the time, especially for product images and hero shots.

For cross-document transitions, the CSS is identical – you just put it in both pages’ stylesheets:

/* This works cross-document. Same selectors, same fix. */
/* Put it in your shared CSS file that both pages load. */
@view-transition {
  navigation: auto;
}

::view-transition-old(hero-img),
::view-transition-new(hero-img) {
  object-fit: cover;
}

/* You can also control the animation timing on the group */
::view-transition-group(hero-img) {
  animation-duration: 0.4s;
  animation-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
}

Honestly, I think object-fit: cover should be the default on these pseudo-elements instead of fill. I get why the spec chose fill – it’s predictable, it matches what object-fit defaults to on replaced elements everywhere else in CSS – but in practice, how often do you actually want a stretched bitmap during a transition? Almost never. You’ll be adding this override on basically every image transition you build.

One more variant that’s useful when the aspect ratios are wildly different – say a tall portrait thumbnail transitioning into a cinematic widescreen hero:

/* Fine-tune where the crop happens on each side of the transition */
::view-transition-group(hero-img) {
  overflow: hidden;
  border-radius: 8px; /* keep it pretty mid-flight */
}

::view-transition-old(hero-img) {
  object-fit: cover;
  object-position: center center;
}

::view-transition-new(hero-img) {
  object-fit: cover;
  object-position: center top; /* keep the top of the hero visible */
}

You can set different object-position values on old versus new, which lets you control where the crop happens on each side of the transition independently. The old thumbnail might look best cropped from center. The new hero might need to anchor to the top. Mix and match.

This took me an embarrassingly long time to figure out. The fix is two lines of CSS, but if you don’t know the pseudo-element tree exists, you don’t even know what to target. Now you do.

The Two Events That Tie it All Together

You’ve already seen pagereveal and pageswap show up in the code above, but let’s take a step back and talk about what they actually are. Understanding these two events is going to be important, because in Part 2 we’ll lean on them heavily for the just-in-time naming pattern that makes view transitions actually scale.

Cross-document view transitions happen across two pages that have no JavaScript connection to each other. Page A doesn’t know about Page B’s DOM. Since the old and new pages have no way to communicate directly, these events are your only way to coordinate the transition on both sides. Page B didn’t exist when Page A was running. So how do you coordinate anything? How do you decide which elements to name, or customize the transition based on where the user is heading?

That’s what these two events are for. They’re your hooks into the transition lifecycle, one on each side of the navigation.

pageswap fires on the outgoing page, right before it gets replaced. This is your last chance to touch the old page’s DOM before the browser snapshots it. The event gives you two key properties:

event.viewTransition: the ViewTransition object for this navigation, or null if no transition is happening.
event.activation: a NavigationActivation object that tells you where the user is going.

That activation property is the really useful one. event.activation.entry.url gives you the destination URL, and event.activation.navigationType tells you whether it’s a push, replace, traverse (back/forward), or reload. This means you can customize the outgoing side of the transition based on the destination. On a product listing page, for example, you can check which product the user clicked, find the matching card, and assign a view-transition-name to just that element right before the snapshot happens.

pagereveal fires on the incoming page, right after the page becomes active but while the transition is still running. This is your chance to set up the new side. The event gives you:

event.viewTransition: same deal, the ViewTransition object or null.

On the incoming page, you check where the user came from using navigation.activation.from.url (via the Navigation API), and you read the current URL from window.location. Between those two pieces of information, you know exactly what kind of navigation just happened and can set up the incoming page’s transition elements accordingly.

Here’s the full lifecycle in order:

User clicks a link on Page A.
pageswap fires on Page A. This is your window to name elements and customize outgoing state.
Browser snapshots the old page (capturing any named elements).
Navigation happens, new page loads.
pagereveal fires on Page B. You can name elements, customize incoming state.
Browser snapshots the new page.
Transition animates between the two snapshots.
viewTransition.finished resolves (or rejects) on both sides.

Three things to keep in mind with these events:

First, always guard with if (!event.viewTransition) return at the top of your handlers. pagereveal actually fires on every navigation – initial page load, back/forward, the works – not just view transitions. If there’s no transition happening, event.viewTransition will be null, and your handler should bail out gracefully. These handlers are transition sugar, not application logic. Never put side effects in them that you need for the page to work.

Second, pageswap only fires if the old page opted into view transitions and the navigation is same-origin. If the user middle-clicks to open in a new tab, or the navigation goes cross-origin, the event either won’t fire or event.viewTransition will be null. That’s fine, your guard clause handles it.

Third, and this is easy to overlook: both events give you access to viewTransition.finished, which is a promise that resolves when the transition completes or rejects if something goes wrong (like a timeout). Always use this for cleanup, as in removing view-transition-name values you set dynamically, resetting state, whatever. Stale names from a previous transition will ruin your next one.

We’ve been using these events lightly so far – a pagereveal listener to catch timeouts, a pageswap listener for logging. In Part 2 of this little series, they become the backbone of the whole scaling strategy. Stay tuned.

What’s Next

That covers the three gotchas that’ll bite you first: the deprecated meta tag that silently does nothing, the 4-second timeout that kills transitions without telling you, and the image distortion that turns every aspect ratio change into a fun house mirror. Plus the two events that give you hooks into the whole lifecycle.

In Part 2, we’ll tackle the scaling problem. When you’ve got a grid of 48 product cards and each one needs a unique view-transition-name, how do you keep your CSS from exploding? The answer involves view-transition-class (which is different from view-transition-name in ways that aren’t obvious), a just-in-time naming pattern using the pageswap and pagereveal events we just covered. And one critical note: we’ll cover prefers-reduced-motion in Part 2, but if you take nothing else from this series, take this: animations can literally make people physically nauseous. Always check that preference and respect it.

The gotchas are behind you. Now it’s time to make it scale.

Cross-Document View Transitions Series

The Gotchas Nobody Mentions (You are here!)
Scaling View Transitions Across Hundreds of Elements (Next Monday!)

12 tendencias UX/UI de 2026 que ya tienen coste para tu negocio

Mon, 18 May 2026 12:19:56 +0000

El diseño de interfaces dejó de ser un asunto del departamento de producto. En 2026, cada decisión de UX/UI tiene un correlato directo en conversión, en regulación o en cuota de mercado. Las empresas que siguen tratando el diseño como una capa estética —algo que se decide cuando «ya está el producto»— están pagando esa confusión en euros contantes y sonantes. Estas son las 12 tendencias UX/UI de 2026 que todo directivo necesita entender, no como modas visuales, sino como palancas de negocio.

1. Generative UI: la interfaz que se rediseña sola

La Interfaz de Usuario Generativa (GenUI) es el salto más radical de los últimos años en diseño UX 2026: sistemas que no solo adaptan el contenido, sino que reestructuran el layout completo en tiempo real según el contexto del usuario. No es personalización de contenido. Es personalización de la arquitectura de la pantalla.

Gartner estima que para finales de 2026 más del 80% de los productos digitales maduros habrán incorporado alguna forma de IA generativa en la capa de interfaz. Las empresas que lo implementan bien reportan mejoras de conversión de entre el 15% y el 25%. El error habitual: usar GenUI para mostrar más cosas al usuario, en lugar de mostrar menos cosas mejores.

2. Agentes de IA como nuevos usuarios: diseña para máquinas que navegan por ti

Hay algo que la mayoría de los equipos de diseño no han asimilado todavía: sus interfaces las navegan cada vez más agentes automatizados, no personas. Asistentes de IA que compran, reservan, comparan y gestionan en nombre de sus usuarios. Diseñar solo para el ojo humano ya es diseñar a medias.

Un estudio publicado en 2026 por IEEE demuestra que los dark patterns son efectivos en más del 70% de los casos cuando el usuario es un agente de IA, frente al 31% cuando se trata de humanos. Esto tiene dos lecturas: si los utilizas, te expones a sanciones regulatorias crecientes; si no los usas, tienes una ventaja competitiva real frente a sitios que todavía los incluyen.

3. Diseño espacial sin necesidad de gafas

La estética del spatial design —profundidad, capas, sombras con volumen, elementos que «flotan»— ha salido de los headsets de Apple Vision Pro y Meta Quest para instalarse en pantallas convencionales. Es una respuesta al agotamiento visual del flat design extremo: los usuarios perciben interfaces con materialidad como más confiables y más premium.

No es necesario tener un producto de realidad aumentada para adoptarlo. Se aplica en composiciones web, dashboards y apps móviles con jerarquías visuales tridimensionales que comunican prioridad sin necesidad de texto adicional.

4. Dark patterns bajo fuego regulatorio: el coste ya es real

El 97% de las apps más populares en la UE contienen al menos un dark pattern, según datos de 2026. El Reglamento de Servicios Digitales (DSA) en su Artículo 25 prohíbe explícitamente las interfaces manipuladoras, con sanciones de hasta el 6% de los ingresos globales. La aplicación efectiva de multas comenzó en el primer trimestre de 2026.

Esto ya no es un debate ético. Es un riesgo de compliance que los departamentos legal y financiero deben tener sobre la mesa. Los equipos de diseño necesitan auditorías de dark patterns igual que los equipos de desarrollo hacen auditorías de seguridad.

5. Hiperpersonalización dinámica: del segmento al individuo

La personalización por segmentos —mostrar contenido diferente a «usuarios de Madrid mayores de 35 años»— es la versión obsoleta del problema. La hiperpersonalización dinámica de 2026 construye recorridos únicos por usuario en tiempo real: interfaces, mensajes y flujos que cambian según el comportamiento, la intención y el contexto en ese momento exacto.

El 60% de los usuarios vuelve a una plataforma si la experiencia estaba bien personalizada. El 88% no regresa si la experiencia fue mala. Son los dos extremos del mismo vector: la experiencia ya no se valora como un extra, se exige como mínimo.

6. Zero UI: cuando la mejor interfaz es ninguna

Zero UI no significa ausencia de diseño. Significa que el punto de contacto entre el usuario y el sistema no es una pantalla: es la voz, el gesto, el contexto. Para 2026, se estima que 157 millones de personas solo en Estados Unidos utilizarán asistentes de voz de forma regular. En España, la adopción crece especialmente en el segmento de 45 a 65 años, el perfil exacto de muchos decisores de compra B2B.

Las empresas que están ganando en este espacio no están diseñando «una funcionalidad de voz». Están rediseñando flujos enteros desde cero asumiendo que la voz es el canal primario, no un complemento.

7. Sostenibilidad digital (Green UX): eficiencia que también convierte

El Green UX parte de una premisa técnica —reducir el peso de las interfaces para consumir menos energía y ancho de banda— pero tiene consecuencias directas en rendimiento. Una interfaz más ligera carga más rápido. Un segundo de mejora en el tiempo de carga puede suponer entre un 7% y un 10% más de conversiones, según datos consolidados del sector.

En 2026, la sostenibilidad digital también impacta en percepción de marca, especialmente en sectores B2B donde los criterios ESG forman parte del proceso de evaluación de proveedores.

8. Accesibilidad obligatoria: la Ley Europea ya tiene fecha

La European Accessibility Act entró en vigor para productos y servicios nuevos en 2025 y se aplicará a todos los productos digitales antes de 2030. Los equipos de diseño que tratan la accesibilidad como un checklist de última hora están construyendo deuda técnica y legal al mismo tiempo.

En 2026, la accesibilidad digital va más allá de las discapacidades visuales clásicas. Incluye diseñar para neurodivergencias, distintos niveles de alfabetización digital y contextos de uso extremos —conducción, baja luminosidad, pantallas pequeñas. Un 23% de los usuarios europeos activos tiene algún tipo de condición que afecta a su interacción con interfaces digitales.

9. Modo oscuro como estándar, no como opción

El 82% de los usuarios tiene el modo oscuro activado por defecto en sus dispositivos. Las plataformas que lo tratan como una «preferencia alternativa» están degradando la experiencia de casi nueve de cada diez usuarios. Las interfaces diseñadas nativamente en dark mode —no como inversión de colores, sino con su propia jerarquía y paleta— han demostrado reducir la tasa de rebote hasta en un 60% y aumentar las páginas por sesión en un 170%.

La trampa habitual: asumir que si el sistema operativo gestiona el cambio de modo, el diseño ya está cubierto. No lo está. Las transiciones automáticas destruyen la jerarquía visual si no se ha diseñado la capa oscura desde el principio.

10. Micro-interacciones y motion design: el lenguaje silencioso de la conversión

El 50% de los diseñadores ya integra micro-interacciones y animaciones en sus proyectos actuales. No como adorno: como comunicación funcional. Una animación bien ejecutada en un formulario de pago elimina la ansiedad del usuario y reduce el abandono. Un feedback visual en tiempo real durante el onboarding puede incrementar la tasa de finalización en más de un 30%.

El criterio para usar motion design en 2026 es sencillo: si la animación no le dice al usuario algo que el texto no puede decir mejor, sobra. Si lo dice mejor, es imprescindible.

11. IA explicable: la transparencia como ventaja competitiva

Los usuarios de 2026 saben que hay IA detrás de las recomendaciones, los precios dinámicos y los rankings de búsqueda. Lo que exigen es que el sistema sea capaz de explicarse. Los productos que muestran su razonamiento —»te recomendamos esto porque has consultado X»— generan más confianza y más retención que los que presentan resultados sin contexto.

El 54% de los responsables de producto reconocen que sus empresas están implementando IA en la interfaz sin una lógica clara para el usuario. Esta brecha entre lo que el sistema hace y lo que el usuario entiende es hoy uno de los principales focos de fricción y abandono en productos digitales.

12. Investigación continua: el fin del UX por proyecto

El modelo tradicional —investigar al inicio del proyecto, entregar, olvidarse— está siendo reemplazado por sistemas de investigación continua donde el feedback del usuario se recoge, procesa e integra de forma permanente. No como una encuesta trimestral: como un sistema vivo que alimenta decisiones de producto cada semana.

Las empresas que operan con este modelo detectan problemas de experiencia antes de que se conviertan en problemas de retención. La diferencia entre corregir un flujo de checkout con tres semanas de datos y hacerlo con tres días de datos puede ser, en volúmenes medios, decenas de miles de euros en ingresos recuperados.

La pregunta que tiene respuesta

¿Cuántas de estas 12 tendencias UX UI 2026 están ya integradas en la hoja de ruta de producto de tu empresa? Si la respuesta es «ninguna» o «estamos evaluándolo», el problema no es de diseño. Es de velocidad de decisión. Las empresas que están ganando en experiencia digital no esperan a que la tendencia esté consolidada. Se posicionan cuando todavía hay ventana.

En Inprofit trabajamos con empresas que quieren convertir su interfaz en una palanca de negocio real, no en un coste de mantenimiento. Cuéntanos qué está frenando tu experiencia digital.

Preguntas frecuentes sobre tendencias UX/UI 2026

¿Qué es el Generative UI y cómo afecta a las empresas en 2026?

Generative UI son sistemas de interfaz que reorganizan su estructura visual en tiempo real en función del contexto del usuario, sin intervención humana. No adaptan contenido: adaptan la arquitectura completa de la pantalla. Las empresas que lo implementan correctamente registran mejoras de conversión del 15-25%, según datos del sector de 2026.

¿Qué multas aplica el DSA por dark patterns en interfaces digitales?

El Reglamento de Servicios Digitales (DSA) de la UE, en su Artículo 25, prohíbe las interfaces manipuladoras con sanciones de hasta el 6% de los ingresos globales de la empresa. La aplicación efectiva de estas multas comenzó en el primer trimestre de 2026 y afecta a todas las plataformas con presencia en el mercado europeo.

¿Cuál es la diferencia entre personalización e hiperpersonalización en UX?

La personalización adapta contenido a segmentos de usuarios. La hiperpersonalización dinámica construye recorridos individuales en tiempo real para cada usuario, ajustando no solo qué se muestra, sino cómo se estructura la interfaz, el tono del mensaje y el orden de los pasos, en función del comportamiento en ese momento exacto.

¿A qué empresas afecta la European Accessibility Act en 2026?

Afecta a todas las empresas que ofrezcan productos o servicios digitales en la Unión Europea: webs, apps, software de autoservicio y plataformas de comercio electrónico. Entró en vigor para nuevos productos en 2025 y se aplicará a todos los productos digitales existentes antes de 2030.

La entrada 12 tendencias UX/UI de 2026 que ya tienen coste para tu negocio se publicó primero en Inprofit.

[Repost] CSS or BS

Mon, 18 May 2026 05:21:29 +0000

Keith Cirkel, in CSS or BS

Well this is a fun (and frustrating!) game. You’ll be presented with 20 (alleged) CSS properties, but some of them… are convincing-looking fakes! You’ve got 10 seconds to identify whether each is real or not. Every few you get right increases the difficulty level, but also the score potential. How high can you score?

Me? Oh, I kept getting up into the “forbidden” level and then my brain would melt and I’d crash out. Quite proud of my last run, though:

👏 Congratulations on being an RSS user. 🎉

Dynamically-Deployed Static Site Subdomains on Caddy – Dan Q

Mon, 18 May 2026 05:21:29 +0000

I’ve recently been experimenting with where I host my small and open-source static sites. In my latest experiment, I wanted to try a low-maintenance selfhosting solution¹. Here’s what I wanted:

Pushing to the main branch of my GitHub/Codeberg/wherever repo would send a webook to my server.
Upon receiving the webhook, my server would pull the latest changes².
Using a wildcard certificate, my webserver automatically mounts each project at a subdomain matching its project name³.

Here’s what I came up with:

Step 1: webhook handler

I’m using Caddy as my webserver, because despite its considerable power and versatility it’s a breeze to set up. To sort wildcard DNS later I’ll want to swap in a custom build, but to get started I just ran apt install caddy. Then I used apt install webhook to install Adnan Hajdarević’s webhook endpoint, and tied the two together in my Caddyfile:

Then I created a webhook in a GitHub repository:

I generated a long random string to use as the secret, and kept a copy for later.

When you create a webhook in GitHub it immediately sends a test event, but it doesn’t quite look like a real push event so I pushed an inconsequential change to the repo to trigger another. Once you’ve got a “real” one sent, you can re-send it via the “Recent Deliveries” tab as many times as you like, to help with testing.

Then, on the server, I checked-out a copy of the code (anonymously: this is a public repository so I don’t need keys to read from it anyway) and set up my /etc/webhook.conf to expect these calls:

[
    {
      "id": "github-push",
      "execute-command": "/var/www/github-push/webhook.sh",
      "command-working-directory": "/var/www/github-push/",
      "pass-arguments-to-command": [
        {
          "source": "payload",
          "name": "repository.name"
        }
      ],
      "trigger-rule": {
        "and": [
          {
            "match": {
              "type": "payload-hash-sha256",
              "secret": "[MY SECRET KEY HERE]",
              "parameter": {
                "source": "header",
                "name": "X-Hub-Signature-256"
              }
            }
          },
          {
            "match": {
              "type": "value",
              "value": "refs/heads/main",
              "parameter": {
                "source": "payload",
                "name": "ref"
              }
            }
          }
        ]
      }
    }
  ]

The trigger-rule directives ensure that (a) the secret key is correct (it uses a HMAC hash across the entire JSON request, so it prevents payload tampering too) and (b) the event only triggers on pushes to the main branch. The execute-command specifies the Bash script I want to run when the webhook is triggered. The pass-arguments-to-command configuration says to send the repo name on to that script.

Now all I needed to do was write the /var/www/github-push/webhook.sh Bash script so that it pulled the latest copy of the code when triggered:

I was able to test this by pushing inconsequential changes to my codebase and watching them get replicated down to my webserver. Neat!

Step 2: low-maintenance webserver

After pointing the DNS for *.static.duckling.danq.me at my static server, I set about configuring Caddy to be able to use DNS-01 challenges to get itself wildcard SSL certificates⁴. Caddy can’t do DNS-01 challenges out of the box, so you either need to write your own renewal script or compile Caddy with plugins corresponding to your DNS provider. My domains’ DNS are managed by a mixture of AWS Route 53, Gandi, and Namecheap, so my xcaddy build step looked like this:

Of course, if I’d have preferred somebody else build it for me, CaddyServer’s download configurator would have done it for me on-demand.

For Gandi and Namecheap I just need a personal access token or API key, respectively, but Route 53’s configuration is slightly more-involved: I needed to create a new user via IAM and give it permission to write DNS TXT records for the appropriate hosted zone. Fortunately the guide for the caddy-dns/route53 repo had an almost copy-pastable example.

I added the AWS access key and secret key as environment variables (like this!) into my /etc/systemd/system/multi-user.target.wants/caddy.service service definition, and then told my Caddyfile to make use of them when renewing the wildcard certificate:

*.static.duckling.danq.me {
    tls {
        dns route53 {
          access_key_id {env.AWS_ACCESS_KEY_ID}
          secret_access_key {env.AWS_SECRET_ACCESS_KEY}
        }
      }
      root * /var/www/github-push/{http.request.host.labels.4}
      file_server
    }
}

The {http.request.host.labels.4} refers to the fourth part of the domain name, when separated at the dots and counted from the right, so 0 = me,

1 =
                danq

, 2 = duckling, 3 = static, and 4 = the part that we’re interested in. So long as I don’t store any other directories in the /var/www/github-push/ directory then this will simply map each subdomain onto its git repository name and return a 404 for any other request.

DNS-01 challenges are necessarily slower than HTTP-01/ALPN challenges, because they’re limited by DNS propogation, so it took a while before the certificate was issued. I ran Caddy in the foreground to watch the logs while it did so:

You can see the whole thing working (for now at least; I don’t know if I’m keeping this approach!) by going to e.g. embed-html.static.duckling.danq.me, which dynamically tracks the main branch of the embed-html repo on GitHub.

I don’t yet know if this is going to be the future forever-home of my many static site side projects, but it’s certainly been the most-satisfying experiment to run so-far.

Footnotes

¹ I’ve drifted away from selfhosting simple static sites lately because I’ve accidentally broken them with configuration changes too many times! But I figured I’d be open to in-housing them again if I had a single simple architecture for them all, so I spun up a VPS and gave it a go

² Running a build script or some other static site generation tool is out of scope for now, but I want to be able to confirm that it would be possible in the future.

³ It also needs to be possible for me to map other domain names to it, but that’s a triviality.

⁴ It’s absolutely possible to use tls { on_demand } to do this, but it’s better to use a wildcard certificate which can be pre-generated and doesn’t let people trick your server into making ludicrous numbers of certificate requests by hammering random subdomain names.

Bitsocial - Open Source P2P Network for Social Apps

Sun, 17 May 2026 22:51:25 +0000

Core Features

Bitsocial is free and open source software: the protocol and clients are public, forkable, and open to outside contributions. Anyone can inspect the code, ship improvements, or build a compatible app without asking permission from a company.

Browse source code

Bitsocial is neither federated nor on-chain. Each community is a peer-to-peer swarm using IPFS, closer to BitTorrent than a hosted website: users seed effortlessly, nodes run on cheap hardware, and each community is fully independent and sovereign.

Learn how p2p works

Pure P2P with arbitrary anti-spam challenges

Self-hosting cost

Extremely cheap, runs on Raspberry Pi

Who keeps it online

Community owners + helper seeders

Scaling model

More peers, more bandwidth

Custom anti-spam logic

Built in: challenge can be anything

Takedown choke points

No single choke point

See deep comparison with:

“Your community literally cannot be banned or blocked by anyone, even a government. We solve that problem.”— Esteban Abaroa, Bitsocial founder

Arbitrary Challenges

Anti-spam? Future-proof.

Each node runs its own anti-spam challenge, exchanged purely peer-to-peer with the user. When spam evolves, nodes adapt without changing the protocol.

User

publishes a post

RequestChallenge

Bitsocial node

runs the challenge

Challenge module

any code-backed test

Plug in any challenge

any code
AI-powered moderation
SMS OTP
whatever comes next

“The only Bitsocial innovation is solving spam and DDoS using arbitrary challenges like captchas over p2p.”— Esteban Abaroa, Bitsocial founder

Master Plan

A Call to Action

Bitsocial wins by attracting as many builders as possible. Run your own unstoppable community, develop your own decentralized social app, or even launch your own business on top of Bitsocial. The tide rises with every builder.

Phase 1 — Ongoing

Decentralize imageboards and forums

Imageboards are the simplest form of social media to decentralize: anonymous posting, few default boards, and no profile graph. 5chan proves Bitsocial can replace centralized imageboards while removing global admins from the equation.

Bitsocial Forge will launch the first non-custodial RPC service for Bitsocial apps. Bitsocial RPC will let users manage nodes remotely, while preserving the option to self-host or run competing RPC infrastructure. Users will be able to create and manage unstoppable p2p communities from mobile.

Forums add persistent identities, post history, and community management. Seedit is the first prototype Bitsocial app for Reddit-style discussion, and public RPC makes those always-on P2P communities practical from anywhere.

Try 5chan Try Seedit Build your own

Phase 2

Launch Bitsocial Network

In order to decentralize all social media, Bitsocial apps will need killer features and strong network effects: unstoppable financial structures, decentralized Bitsocial domains (.bso), awards and tipping, common liquidity, and practical monetization. All of this will be powered by Bitsocial Network, a decentralized appchain solution for Bitsocial apps.

Learn More: Launch Bitsocial Network

Phase 3

Launch the flagship Bitsocial app

The flagship Bitsocial app should be the first profile-based client: posts, replies, follows, real-time public conversation, and communities that can pull network effects from every Bitsocial client. By default, it can feel as familiar as a modern For You social app, while still letting users switch RPCs, feeds, instances, algorithms, ads, or remove ranking entirely.

Through non-custodial RPC, each user can still act as a full p2p node without trusting the RPC with ownership. Anyone should be able to move to their own profile node on a low-spec machine, including a Raspberry Pi, whenever they want.

Because Phase 2 gives the app an unstoppable crypto financial layer, the flagship client can potentially become an everything-app without turning into a custodial platform.

Learn More: Launch the flagship Bitsocial app

Phase 4

Scale Bitsocial economies

The next layer is ecosystem funding and infrastructure pluralism. Bitsocial Forge's RPC should not be the only successful RPC: many businesses, independent teams, anonymous operators, and community entities should build RPCs, media hosting, discovery, moderation, and other services on top of Bitsocial. Funding should push that decentralization forward, so developers and operators can compete to make the network faster, cheaper, more reliable, and harder to capture.

Learn More: Scale Bitsocial economies

Phase 5

Decentralize all social media

With the core apps, public RPCs, profile nodes, discovery, and monetization in place, Bitsocial can fund and build the long tail of social clients: blogging, crowdfunding, creator video and a credible YouTube alternative, niche experiments, and every format too early for the first four phases. Bitsocial Forge can build some of them, centralized clients can compete too, they do not all have to be FOSS, and decentralized community grants can fund as many developers as possible.

Learn More: Decentralize all social media

The end state is not one app. It is a market of clients, nodes, services, and communities that can replace platform ownership with protocol competition.

Social media finally finds its equilibrium: a fully decentralized, peer-to-peer social network that nobody owns; Bitsocial.

Stay in the Loop

Get notified about protocol milestones, new Bitsocial apps, and ecosystem updates. Low frequency, high signal.

No spam, ever. Unsubscribe anytime.

Why Are My Emails Going to Spam? Reasons and How to Fix Them

Sat, 16 May 2026 11:17:45 +0000

You set up SPF, DKIM, and DMARC. Your subject line is clean. Your content is not salesy at all. And still, your emails are going to spam. It is one of the most disorienting deliverability problems because nothing looks obviously wrong, yet something clearly is.

The truth is that spam filters today are far more layered than most senders realize. They evaluate your domain reputation, engagement signals, sending patterns, list quality, and content structure all at once. Missing the mark on any one of them can quietly push your emails into the spam folder, even when everything else looks fine.

In this blog, we will walk through every real reason your emails might be landing in spam, how each fix works step by step, and what you need to maintain over time to stay in the inbox.

TL;DR

Authentication is necessary but not sufficient on its own
Sender reputation, list quality, and engagement rates are equally critical
Content structure, HTML quality, and sending volume patterns all affect spam scoring
Gmail and Yahoo now enforce one-click unsubscribe and stricter spam rate thresholds
Most deliverability problems have a root cause that compounds over time — fix the foundation first

What spam filters are actually evaluating

Spam filters are not simple keyword detectors. Gmail, Outlook, Yahoo, and other providers use multi-signal algorithms that assign a score to each incoming email. If that score crosses a set threshold, the email goes to spam regardless of your intent.

According to Statista, “nearly 45.6% of all emails worldwide were identified as spam in 2023.” That number climbed above 46.8% by December 2024. Spam filters have tightened dramatically in response to this volume, and legitimate senders now regularly get caught in rules designed for bad actors.

The signals these filters evaluate include your sending domain reputation, IP address history, whether your authentication records are properly configured, how recipients engage with your emails, whether you have clean list hygiene, and whether your content or formatting resembles known spam patterns. All of it runs together. That is why a technically clean email can still land in spam if your domain reputation is weak or your engagement rates have dropped.

Why are my emails going to spam?

The reasons fall into distinct categories. Understanding which one applies to you is the first step toward fixing it.

1. Authentication Is missing or misconfigured

Email authentication is the technical baseline every sender needs before anything else matters. Three protocols work together to establish your legitimacy with receiving mail servers.

SPF (Sender Policy Framework) defines which IP addresses are authorized to send mail on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing emails that proves they were not altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together and tells receiving servers what to do when either check fails — reject the message, quarantine it, or let it pass.

When any of these records are missing, incorrectly formatted, or in conflict with each other, spam filters flag the email almost immediately. Missing DMARC alone is enough to cause consistent spam folder placement, even when your content is perfectly fine.

How to fix it, step by step:

Step 1: Log into your domain registrar or DNS provider and check whether SPF, DKIM, and DMARC TXT records exist for your sending domain.
Step 2: Use a free tool like Google Postmaster Tools or MXToolBox to verify that each record is correctly configured and passing checks.
Step 3: If DMARC is missing, add a basic record starting with a p=none policy, which monitors without blocking, then move to p=quarantine and eventually p=reject once you have confirmed all legitimate mail streams are authenticated.
Step 4: After any changes to your DNS records, re-test using MXToolBox to confirm the records propagated correctly.
Step 5: Repeat this verification process whenever you change email service providers or add a new sending tool.

As Google’s Neil Kumaran stated when announcing Gmail’s new 2024 requirements, “Starting in 2024, we’ll require bulk senders to authenticate their emails, allow for easy unsubscription and stay under a reported spam threshold.” Authentication is no longer optional at any sending volume.

2. Weak sender reputation

Your domain and sending IP both carry a reputation score that mail providers track over time. This score is built from your cumulative sending history, including bounce rates, spam complaint rates, engagement levels, and whether your sending volume is consistent.

A brand-new domain starts with no reputation at all, which is why new senders often struggle with deliverability even when doing everything correctly. A domain that has previously sent to poor-quality lists, generated complaints, or been associated with spam activity can develop a damaged reputation that takes months to repair.

If you are using a shared IP address through your email service provider, you also inherit some of the reputation of other senders on that same IP. This is one reason why reputable ESP infrastructure matters.

How to fix it, step by step:

Step 1: Set up Google Postmaster Tools for your sending domain to monitor your Gmail-specific domain reputation score.
Step 2: Check your domain and IP against public blocklists using MXToolBox or MultiRBL to see whether you appear on any known spam databases.
Step 3: If your reputation is poor, stop all large-volume sends immediately and focus on sending small batches only to your most engaged subscribers.
Step 4: Gradually increase volume as your engagement metrics improve, which signals to mail providers that your emails are wanted.
Step 5: Maintain this gradual, consistent sending pattern going forward, since sudden spikes after quiet periods look like compromised account behavior.

3. High bounce rates

Every hard bounce, which occurs when an email address does not exist, sends a negative signal to mail providers. A pattern of high hard bounces tells spam filters that you are not maintaining your list, and that behavior is strongly associated with purchased lists and scraping tactics.

Even a bounce rate above 2% starts to damage your sender reputation meaningfully. Most professional email programs aim to keep hard bounces below 0.5%.

How to fix it, step by step:

Step 1: Run your existing list through an email verification tool before your next send to identify invalid addresses.
Step 2: Remove every hard bounce immediately after it occurs. Do not send to a hard-bounced address again.
Step 3: Implement double opt-in for all new sign-ups so that unverified or mistyped addresses never make it onto your active list.
Step 4: Monitor your bounce rate report after every campaign and investigate any sudden increases, since a spike often indicates a form abuse problem or a data import issue.
Step 5: Review your email mana g ement practices across your team to ensure list hygiene is treated as an ongoing process rather than a one-time cleanup.

4. Low recipient engagement

This is the reason most senders overlook, and it is increasingly the deciding factor for Gmail placement. Mail providers track how recipients interact with your emails. When a large portion of your list consistently ignores your emails, never opens them, never clicks anything, and never replies, those engagement signals tell spam filters that your emails are not wanted.

Over time, consistent low engagement pushes your emails further into spam or the promotions tab. The filter is not judging your content in isolation. It is comparing your emails to what that specific recipient typically engages with, which means personalization and relevance matter far more than generic broadcast messaging.

How to fix it, step by step:

Step 1: Segment your list and identify subscribers who have not opened or clicked any email in the past 90 days.
Step 2: Send a re-engagement campaign to that segment. Ask them directly whether they still want to receive your emails.
Step 3: Remove anyone who does not respond to the re-engagement campaign within a reasonable window. A smaller, engaged list delivers better inbox placement than a large, disengaged one every time.
Step 4: Improve the relevance of your content by sending based on subscriber interest, behavior, or purchase history rather than blasting the entire list with every send.
Step 5: Monitor your open rates, click rates, and spam complaint rates after every send using your email platform’s analytics.

5. Spam trigger words and content issues

Content is still a factor, though modern spam filters weigh it less heavily than reputation signals. Certain patterns in your subject line, preview text, or email body can push your spam score up enough to cause placement issues, especially with smaller mail servers and corporate inboxes that still rely heavily on content filtering.

Subject lines with all-caps words, multiple exclamation marks, or aggressive sales phrases like “ACT NOW,” “LIMITED TIME,” or “100% FREE” are among the fastest ways to trigger a filter. The same applies to misleading preview text, excessive links, and emails that are almost entirely images with very little actual text.

Broken or messy HTML is another content-layer trigger. Sloppy code is a known pattern in spam because bad actors do not take the time to clean their markup. Even legitimate senders using poorly formatted templates can get flagged as a result.

How to fix it, step by step:

Step 1: Review your subject line and preview text for aggressive promotional language. Write copy that is specific and honest rather than urgency-driven.
Step 2: Aim for a text-to-image ratio of roughly 60% text and 40% images. Do not send emails that are entirely image-based.
Step 3: Add descriptive alt text to every image in your email.
Step 4: Remove URL shorteners like bit.ly from all email links. Use your own domain for tracking links instead.
Step 5: Use a tested email template with clean HTML. Run your email through an HTML validator before sending and check rendering across multiple clients if possible.
Step 6: Avoid attaching files to marketing emails. If you need recipients to download something, host it on your website and link to it.

6. No unsubscribe option

A missing or broken unsubscribe link is both a legal violation and a direct deliverability risk. When recipients cannot easily opt out, they hit the spam button instead. Each spam report damages your sender reputation and increases the likelihood that future emails land in spam for everyone on your list.

The CAN-SPAM Act requires a clear, working unsubscribe mechanism in every commercial email. GDPR adds further requirements for EU recipients, including documented consent and prompt removal.

Beyond compliance, Google’s official 2024 sender requirements now mandate one-click unsubscribe for all bulk senders sending to Gmail. Unsubscribe requests must be processed within two days. Yahoo has implemented equivalent requirements.

How to fix it, step by step:

Step 1: Add a visible, clearly worded unsubscribe link to the footer of every commercial email you send.
Step 2: Implement the List-Unsubscribe header in your email’s technical setup so that Gmail and other providers can surface the unsubscribe option directly in their interface.
Step 3: Process unsubscribe requests within 48 hours. Do not continue sending to any address after they have requested removal.
Step 4: Audit your templates to confirm the unsubscribe link actually works. Broken links are treated the same as a missing link by spam filters.

7. Sudden volume spikes

Sending a few hundred emails one week and tens of thousands the next is a classic spam signal. Mail providers expect gradual, consistent growth in sending volume. A sudden spike suggests either a compromised account or mass spam activity, and filters respond accordingly.

This matters most when you are launching a new campaign to a previously unused segment, switching to a new email service provider, or sending to a purchased or imported list for the first time.

How to fix it, step by step:

Step 1: Plan any volume increase gradually. A safe approach is to increase your daily sending volume by no more than 20% to 30% per week.
Step 2: If you are migrating to a new sending infrastructure, warm up the new domain or IP by sending first to your most engaged subscribers in small batches.
Step 3: Monitor your spam complaint rate and bounce rate closely during any volume ramp-up.
Step 4: Schedule your campaigns in advance so that sending volume is spread across days rather than concentrated in a single blast.

8. Unprotected sign-up forms

Form abuse is an underappreciated but real cause of spam problems. Bots and automated scripts will fill out unprotected forms with fake, invalid, or recycled email addresses.

Those addresses then generate hard bounces or trigger spam traps on your first send, which damages your reputation quickly.

How to fix it, step by step:

Step 1: Add CAPTCHA verification or honeypot fields to all sign-up forms to prevent bot submissions.
Step 2: Implement rate limiting on form submissions to block repeated submissions from the same IP address in a short window.
Step 3: Enable double opt-in for all forms. This ensures that only real people with access to the submitted email address end up on your active list.
Step 4: Monitor your list for unusual sign-up spikes, which can indicate an active bot attack on your forms.

9. Sending from a free domain

Using a Gmail, Yahoo, or Hotmail address to send business or marketing emails is a significant deliverability risk. Free domains cannot be properly authenticated for bulk sending the same way a custom domain can, and receiving mail servers treat them with suspicion at any meaningful volume.

Google and Yahoo’s 2024 sender requirements explicitly address this. Bulk sending from a free domain is likely to result in rejection or consistent spam folder placement.

How to fix it, step by step:

Step 1: Register a custom domain for your business if you do not already have one.
Step 2: Set up a professional email address on that domain as your primary sending address.
Step 3: Configure SPF, DKIM, and DMARC records for the custom domain before sending any campaigns.
Step 4: Make sure the “From” name and address are consistent across all your emails so recipients recognize who is sending.

10. Being listed on a blocklist

If your sending domain or IP address appears on a public email blocklist, your messages may be blocked outright or automatically filtered to spam on any mail server that queries that list.

Blocklisting can happen because of previous poor sending behavior, because you shared an IP with a bad actor, or because your domain was spoofed in a phishing campaign without your knowledge.

How to fix it, step by step:

Step 1: Check your domain and sending IP regularly against blocklists using MXToolBox or MultiRBL. Check at minimum once per month and after any deliverability incident.
Step 2: If you find yourself listed, do not submit a removal request immediately. First identify and fix the root cause, whether that is a compromised account, poor list hygiene, or high complaint rates.
Step 3: Once the underlying issue is resolved, submit a delisting request to the blocklist operator. Most major lists have a self-service removal process.
Step 4: After removal, monitor your deliverability closely for two to four weeks to confirm the issue does not recur.

The role of List quality in everything

Almost every deliverability problem traces back to list quality at some level. Sending to addresses that did not opt in, keeping inactive subscribers, ignoring bounce data, and failing to process unsubscribes all create conditions that trigger spam filters repeatedly.

A clean, permission-based list with strong engagement signals is the most reliable foundation you can build. Just follow the email list management guide to keep a list healthy over time, including handling bounces, managing inactive contacts, and running proper re-engagement campaigns.

For teams handling high volumes of customer email, structured workflows also matter. Using a system like an email ticketing system helps support teams manage customer conversations in an organized way, which reduces the risk of sending patterns that appear spammy to mail providers due to inconsistent volume or disorganized routing.

Transactional emails go to spam too

A common misconception is that transactional emails, such as order confirmations, password resets, and account notifications, are immune to spam filters. They have better deliverability on average because they are expected and triggered by user action.

But they can still go to spam if your domain reputation is poor, your authentication is broken, or the email content resembles a phishing template.

The best practice is to separate your transactional and marketing email streams using different subdomains. For example, use mail.yourdomain.com for marketing campaigns and notify.yourdomain.com for transactional messages.

This isolation ensures that a spike in spam complaints from a marketing campaign does not drag down the delivery of your critical transactional messages. Many support and product teams handle this using email piping to route replies and notifications cleanly through their infrastructure without mixing streams.

Quick reference: spam fix checklist

Use this after diagnosing your specific issue to confirm you have covered each area:
Verify that SPF, DKIM, and DMARC records are all present, correctly configured, and passing checks.
Remove hard bounces immediately after every send and keep your bounce rate below 0.5%.
Add a working one-click unsubscribe link to every commercial email.
Process all unsubscribe requests within 48 hours.
Remove or suppress subscribers who have not engaged in the past 90 days.
Audit your subject lines and email body for spam trigger words, all-caps text, and misleading copy.
Replace URL shorteners with tracking links on your own domain.
Check your HTML for broken markup before every send.
Check your domain and IP against blocklists at least once per month.
Increase sending volume gradually rather than in sudden spikes.
Add CAPTCHA or honeypot protection to all sign-up forms.
Send from a custom domain with full authentication, never a free email service.

Wrapping up

Emails going to spam is almost never caused by a single obvious mistake. It is usually a combination of signals, any one of which alone might not cause a problem, but together push your emails past the spam threshold.

Authentication is where to start. List quality is where to sustain progress. Engagement is what separates senders who recover from those who never fully do.

Work through each reason methodically, prioritize the ones that apply to your situation, and track your metrics over time. Deliverability rewards consistency more than any single fix.

Want a system that makes ticket handling this smooth? Fluent Support brings structure and clarity to every request so your team always knows exactly what to do next. See how it works.

Explore Fluent Support Now!

FAQs

How do I check if my emails are going to spam without asking recipients?

Use seed testing tools to send your email to a network of test accounts across multiple providers and track placement. You can also use Google Postmaster Tools for Gmail-specific spam rate data. Many ESPs offer inbox placement testing built into their platform.

Does changing the subject line stop emails from going to spam?

The subject line is one content signal among many. A cleaner subject line helps, but if your domain reputation or authentication is broken, changing the subject line alone will not fix inbox placement. Address the technical and reputation issues first.

Why are my emails going to spam in Gmail but not Outlook?

Gmail and Outlook use different spam scoring algorithms with different thresholds and priorities. Gmail places heavy weight on engagement signals and has strict spam rate limits under its 2024 sender requirements.

Outlook prioritizes IP reputation and content filters more heavily. Check Google Postmaster Tools for your Gmail-specific domain reputation and spam rate data.

How long does it take to fix email deliverability issues?

Authentication fixes are immediate. Reputation recovery depends on how damaged the reputation is. Minor issues can resolve in a few weeks.

Significant damage from high complaint rates or blocklisting may take two to three months of consistent, clean sending before inbox placement fully normalizes.

Why are my outreach emails going to spam even when they are personalized?

Cold outreach emails face higher scrutiny because recipients did not opt in. Even well-personalized cold emails get flagged due to domain age, low sender reputation, or content patterns associated with sales prospecting.

Warming your domain gradually, sending low initial volumes, and earning genuine replies all help build the reputation that improves placement over time.

The post Why Are My Emails Going to Spam? Reasons and How to Fix Them appeared first on Fluent Support.

HTTP Error 521: What It Means and How to Fix It Fast

Sat, 16 May 2026 11:17:45 +0000

Your site is live, Cloudflare is active, and then out of nowhere visitors see a blank page that reads “Web server is down.” No warning. No obvious reason. Just a broken connection and lost traffic.

HTTP error 521 is one of those errors that catches site owners off guard because everything on the surface looks fine. Cloudflare is up. Your domain is resolving. But somewhere between the CDN and your origin server, something went wrong.

In this blog, we will cover what HTTP error 521 actually means, what causes it, how to fix it step by step, and how to prevent it from coming back.

TL;DR

HTTP error 521 means Cloudflare reached your server but the server refused the connection
The problem is always on the origin server side, not Cloudflare’s
Common causes: server is offline, firewall blocking Cloudflare IPs, wrong SSL/TLS settings, or incorrect port binding
Fixes include allowlisting Cloudflare IPs, checking server status, and aligning your SSL mode
Site visitors cannot fix this themselves, it requires action from the site owner or host

What Is HTTP Error 521?

HTTP error 521 is a Cloudflare-specific status code that appears when Cloudflare successfully receives a visitor’s request but cannot establish a TCP connection to your origin web server. The server actively refuses the connection rather than simply timing out.

According to Cloudflare’s official documentation, “the two most common causes are an offlined origin web server application and blocked Cloudflare requests.” The error message visitors see typically reads: “Error 521: Web server is down.”

The key distinction here matters. HTTP error 521 is not a Cloudflare failure. Cloudflare is doing its job. The issue sits on your hosting side, which is why your host may tell you “everything looks fine” when you contact them while Cloudflare is still proxying the requests.

How Cloudflare Works (And Why 521 Happens)

Cloudflare operates as a reverse proxy. When a visitor requests your site, they connect to Cloudflare’s edge servers first. Cloudflare then forwards that request to your origin server and returns the response to the visitor.

In a working setup, this happens in milliseconds. With error 521, the handshake breaks at the second step. Cloudflare tries to open a connection on port 80 (HTTP) or port 443 (HTTPS) and gets a “connection refused” response. The origin server is essentially saying no.

This matters for business owners beyond the technical details. Downtime carries real financial cost. According to a Gartner study cited by Atlassian’s incident management research, “the average cost of IT downtime is $5,600 per minute.” For ecommerce stores or SaaS products, even a few minutes of HTTP 521 errors can mean lost orders and damaged customer trust.

What Causes HTTP Error 521?

Understanding the cause narrows down your fix quickly. There are four primary culprits.

Your web server process is down. Apache, Nginx, or whatever web server software you use may have crashed or stopped. The physical server machine itself could still be running, but if the application process stopped, Cloudflare has nothing to connect to.

A firewall is blocking Cloudflare IPs. Because Cloudflare proxies all traffic through its own IP ranges, your origin server receives requests from Cloudflare IPs rather than individual visitor IPs. Security tools like Fail2Ban, iptables, or server-level firewalls can mistakenly flag these as suspicious and block them. As confirmed in Cloudflare’s community troubleshooting tip, “this is one of the most frequently seen causes of error 521.”

SSL/TLS misconfiguration. If your Cloudflare SSL mode is set to Full or Full (Strict) but your origin server has no valid SSL certificate installed, Cloudflare cannot complete a secure handshake. The connection gets refused before any content is served.

Incorrect port binding. Your server may not be listening on port 80 or 443. Cloudflare expects these standard ports. If your web server process is bound to a different port or not bound at all, the connection fails at the TCP layer.

How to Fix HTTP Error 521: Step by Step

1. Check Whether Your Web Server Is Running

Start with the basics. SSH into your server and run a status check on your web server process.

For Nginx:

systemctl status nginx

For Apache:

systemctl status apache2

If the service shows as inactive or failed, restart it:

systemctl restart nginx

You can also use the curl command to test a direct connection to your server’s IP address, bypassing Cloudflare entirely.

If the server responds directly but not through Cloudflare, the problem points toward firewall or configuration issues rather than the server being fully offline.

2. Allowlist Cloudflare IP Addresses

Cloudflare publishes its complete list of IP ranges at cloudflare.com/ips. You need to ensure that all of these addresses are explicitly permitted in your firewall rules.

In your .htaccess file for Apache, add allow from directives for each Cloudflare IP range. For iptables on Linux, use the appropriate accept rules. If you use a hosting control panel like cPanel or a security tool like Fail2Ban, check the whitelist or allowlist settings there.

This step resolves the majority of HTTP 521 errors, particularly those that appear intermittently or only under certain traffic conditions.

3. Align Your SSL/TLS Settings

In your Cloudflare dashboard, go to the SSL/TLS section and check which encryption mode is active.

Flexible: Cloudflare connects to your origin over HTTP. No certificate is required on the origin server.
Full: Cloudflare connects over HTTPS. A certificate must be installed on the origin, but it can be self-signed.
Full (Strict): Requires a valid, trusted certificate on the origin server, either from a certificate authority or a Cloudflare Origin Certificate.

If you are using Full or Full (Strict) without a valid certificate on your origin, the SSL handshake will fail and trigger error 521. Either install a certificate or change the SSL mode to match your actual server setup.

Cloudflare’s free Origin Certificates, available directly through the SSL/TLS section of your dashboard under “Origin Server,” are the cleanest fix for most shared hosting or VPS environments.

4. Confirm Port Binding

Your server must be actively listening on the port Cloudflare expects. For Flexible SSL mode, that is port 80. For Full or Full (Strict), that is port 443.

Run the following command to check what your server is listening on:

netstat -tlnp | grep -E ’80|443′

If neither port shows your web server process in the output, the binding is missing or the process has crashed.

5. Review Server Error Logs

When the cause is not immediately obvious, your server logs usually reveal it. For Nginx, check /var/log/nginx/error.log. For Apache, check /var/log/apache2/error.log. Look for connection refusals, crash reports, or resource exhaustion messages around the time the error first appeared.

6. Temporarily Disable Cloudflare to Isolate the Problem

If you need to confirm whether the issue lies with your Cloudflare configuration or the origin server itself, pause Cloudflare from the Overview section of your dashboard. Once paused, traffic goes directly to your origin. If the site loads normally, the issue is in your Cloudflare settings. If it still fails, the origin server needs direct attention.

HTTP Error 521 in Specific Environments

Ubuntu servers: The fix usually involves verifying whether Nginx or Apache is running via systemctl status, then reviewing iptables rules to confirm Cloudflare IP ranges are not being blocked at the OS level.

Nginx setups: Pay close attention to the listen directives in your Nginx configuration files. If the server block is only configured to listen on a non-standard port, Cloudflare’s connection attempts on 80 or 443 will be refused every time.

WordPress sites: Security plugins like Wordfence can build firewall rules that inadvertently block Cloudflare’s proxy IPs. Temporarily deactivating security plugins and retesting can confirm whether this is the cause. Resource-heavy plugins can also push the server into overload, causing it to stop accepting new connections entirely.

Firestick and streaming apps (Tivimate, Mihon, etc.): When users report HTTP 521 on these platforms, the error is originating from the content server those apps connect to. The app itself is not at fault. There is nothing the end user can do. The server operator on the other side needs to resolve it.

How This Connects to Customer Support Workflows

HTTP error 521 is not only a technical problem. For businesses selling products or services online, server downtime directly affects customer experience and trust.

When users hit error 521, they reach out through email, social media, and support channels looking for answers. Having a reliable support ticket system means those reports get captured and routed to the right team quickly. Without one, messages get buried in inboxes and the problem lingers longer than it should.

A solid customer service workflow should include a step for outage communication. When your site goes down, customers need a timely and clear message. Proactive communication during downtime is one of the most effective ways to preserve trust while the technical fix is in progress. Fluent Support’s guide on proactive customer support covers this in more depth.

Related server errors like 502 Bad Gateway and HTTP error 503 share overlapping diagnostic steps with 521, so having your support team familiar with this category of errors reduces resolution time across the board.

How to Prevent HTTP Error 521 from Recurring

Once you resolve the immediate issue, a few habits keep it from returning.

Set up uptime monitoring using a tool like UptimeRobot so you get alerted the moment your server becomes unreachable, rather than hearing about it from customers first. Always keep Cloudflare’s full IP list allowlisted and review your firewall rules whenever you install new security software or change hosting configurations.

If your site handles regular traffic spikes, consider upgrading your hosting plan before you hit the resource limits that cause web server processes to crash under load. Keeping your SSL certificates renewed and your Cloudflare SSL mode consistently aligned with your origin setup eliminates one of the most avoidable causes of recurring 521 errors.

Wrapping Up

HTTP error 521 points to one specific breakdown: Cloudflare tried to reach your origin server, and the server refused the connection.

The root cause is almost always one of four things, a stopped web server process, Cloudflare IPs being blocked by a firewall, an SSL configuration mismatch, or a port binding issue.

Work through the fixes in order. Start with server status, move to firewall rules, then SSL settings, then port binding. Check your server error logs at any stage if the cause remains unclear.

For visitors who encounter this error, there is no client-side workaround. The resolution sits entirely with the site owner or hosting provider.

Want a system that makes ticket handling this smooth? Fluent Support brings structure and clarity to every request so your team always knows exactly what to do next. See how it works.

Explore Fluent Support Now!

Frequently Asked Questions

What is HTTP error 521 Cloudflare?

It is a status code Cloudflare returns when its edge servers cannot establish a TCP connection to your origin server. The server is actively refusing the connection rather than timing out or being unreachable on the network.

How do I fix error 521 on my web server?

Start by confirming your web server process (Nginx or Apache) is running. Then verify that all Cloudflare IP ranges listed at cloudflare.com/ips are not blocked by your firewall. Finally, check that your Cloudflare SSL/TLS mode matches your origin server’s certificate configuration.

What does HTTP 521 mean on Mihon or Tivimate?

On streaming or manga reader apps, error 521 means the content server those apps connect to is experiencing an origin server refusal of Cloudflare’s connection. The app itself is not the cause. Only the server operator can resolve it.

Can error 521 hurt my SEO?

Yes. If search engine crawlers consistently encounter 521 errors, it signals that the site is unreliable. Extended downtime can lead to ranking drops. Fixing the error promptly and using uptime monitoring to catch future occurrences protects both rankings and user trust.

What is the difference between error 521 and error 522?

HTTP error 521 means the connection was actively refused by the origin server the moment Cloudflare attempted it. Error 522 means the connection was initiated but the origin server failed to respond within Cloudflare’s timeout window. Both point to origin server problems but represent different failure modes at the network level.

What does “Web server is down error code 521 Nginx” mean?

This refers specifically to Nginx as the web server process that has stopped or refused the incoming connection. The fix typically involves restarting the Nginx service with systemctl restart nginx and checking your Nginx configuration for correct port binding on port 80 or 443.

The post HTTP Error 521: What It Means and How to Fix It Fast appeared first on Fluent Support.

How to Submit URLs to Google for Indexing (4 Methods)

Sat, 16 May 2026 11:17:44 +0000

Publishing a page does not mean Google knows it exists. Until Google crawls and indexes your URL, it will not appear in any search result, no matter how good the content is.

That gap between publishing and getting indexed is where a lot of traffic gets lost. Submitting your URL to Google closes that gap faster than waiting for Googlebot to stumble across it on its own.

This guide covers every practical method for submitting URLs to Google, what to do when indexing still does not happen, and the mistakes that quietly slow the whole process down.

TL;DR

What does submitting a URL to Google mean?

Submitting a URL to Google is a manual signal that tells Googlebot to crawl a specific page and consider adding it to the search index. It speeds up discovery but does not guarantee the page will be indexed.

What are the methods for submitting URLs to Google?

The four main methods are the URL Inspection Tool in Google Search Console, sitemap submission, internal linking from already-indexed pages, and the Google Indexing API for automated or high-volume needs.

How do you use the URL Inspection Tool?

Log in to Google Search Console, paste the URL into the search bar at the top, wait for Google to check its index status, then click ‘Request Indexing.’ Google will run a live test and add the URL to its priority crawl queue.

Why would a submitted URL still not get indexed?

The most common reasons are a noindex tag on the page, a robots.txt block preventing crawling, thin or duplicate content, a canonical tag pointing to a different URL, or crawl budget limitations. The URL Inspection Tool surfaces most of these issues in its live test report.

What best practices should I follow when submitting URLs?

Only submit pages with substantive, original content. Fix any technical issues before submitting. Ensure your site uses HTTPS. Do not resubmit the same URL repeatedly. Keep pages mobile-friendly since Google uses mobile-first indexing.

What Does Submitting a URL to Google Actually Do?

Submitting a URL to Google is a manual signal that tells Googlebot to crawl a specific page and consider adding it to the search index. It does not guarantee indexing, and it does not influence rankings. What it does is move your page into Google’s priority crawl queue, which speeds up the discovery process compared to waiting for natural crawling.

Without submission, Google finds pages through links, sitemaps, or revisiting previously crawled pages. For new sites, pages with few backlinks, or freshly updated content, that natural process can take days to weeks. Submitting directly cuts that waiting time significantly.

Methods to submit URLs to Google

There are four reliable ways to submit URLs to Google for indexing:

Use the URL Inspection Tool in Google Search Console
Submit a sitemap through Google Search Console
Add internal links from already-indexed pages
Use the Google Indexing API for automated bulk submission

Each method serves a different situation. The sections below break down exactly how to use each one.

Method 1: Use Google Search Console’s URL Inspection Tool

The URL Inspection Tool in Google Search Console is the easiest way to submit your URLs to Google. It’s like handing Google a VIP ticket to your latest content.

Here’s how to use it step by step:

Step 1: Log in to Google Search Console. (If you don’t have an account yet, don’t worry. I’ve included instructions in the note below. It’s totally free and straightforward)

Step 2: Paste your URL into the search bar at the top of the dashboard. Or you can click on the URL inspection and paste it.

Step 3: The tool will check if your URL is already indexed. If it’s not, you’ll see a “Request Indexing” button. Click it, and you’re done!

A shout-out for Google Search Console. This inspection tool is super efficient. It lets Google know about your pages almost instantly.

Note: How to sign up for Google Search Console and add your site

First, go to Google Search Console. Then click the “Start Now” button and log in with your Google account. Then, add your website with the URL prefix. Now, it’s time to verify ownership by following one of the provided methods: HTML file, HTML tag, Google Analytics, Google Tag Manager, and Domain name provider.

And done! You can now unlock all the features of Google Search Console (well, well, you have hired a dedicated website assistant).

Method 2: Submit a sitemap through Google Search Console

If the URL Inspection Tool is your one-on-one chat with Google, submitting a sitemap is like sending Google a formal invitation with all your website’s details.

With sitemap submission, you let Google discover multiple URLs at once. This could be a great time saver, especially when managing a large site.

Note: A sitemap is an XML file that informs search engines about all your important pages. It helps Google and other search engine crawlers to find and index your content more efficiently.

To submit a sitemap, follow these instructions:

Step 1: Create a sitemap. If you’re using WordPress, plugins like Yoast SEO or Rank Math can generate one automatically. Or you can create your sitemap with another plugin XML Sitemap Generator for Google.

Again, if you are a non-WordPress user, online sitemap generator tools could be a good option.

Step 2: Locate your sitemap URL. It usually looks something like this: https://yourwebsite.com/sitemap_index.xml.

Step 3: Go to Google Search Console and navigate to the Sitemaps section (it’s in the ‘Indexing’ tab).

Step 4: Paste the sitemap URL into the provided field and hit “Submit.”

And that’s it!

You’ve handed Google a comprehensive map of your website.

Easy-peasy.

Method 3: Internal Linking from Indexed Pages

Internal links are one of the most underused methods for getting new pages crawled. When you add a link to a new page from an existing, already-indexed page, Googlebot follows that link during its next crawl of the source page and discovers the new URL naturally.

This matters especially for pages with limited external backlinks. A page that exists only in your sitemap or is completely isolated has low crawl priority. Linking to it from a high-traffic or frequently crawled page on your site raises its discoverability significantly.

The best places to add internal links to a new page are your homepage, relevant category pages, high-traffic blog posts on related topics, and any hub pages that aggregate content on the same subject. Use descriptive anchor text that reflects what the new page is actually about.

Method 4: Google Indexing API (For High-Volume or Automated Needs)

The Google Indexing API lets you notify Google programmatically when a URL has been added or removed. It was originally built for job posting and livestream pages, but many site owners use it more broadly for faster indexing of any content type.

Setting it up requires a Google Cloud project, a service account with Search Console owner permissions, and some basic API calls. Tools like Rank Math’s Instant Indexing plugin for WordPress wrap this API into a one-click setup, making it accessible without developer knowledge.

This method is worth considering if you publish large volumes of content regularly and need indexing to happen faster than manual requests allow. For smaller sites or occasional new posts, the URL Inspection Tool and sitemap approach are sufficient.

Why Your Page Still Is Not Indexed After Submission

Submitting a URL does not guarantee indexing. Google makes its own decision about whether a page belongs in the index, based on quality signals, technical factors, and crawl budget. These are the most common reasons a submitted URL fails to get indexed.

The page has a noindex tag

A noindex directive in the page’s meta robots tag or HTTP header tells Google explicitly not to index it. This overrides any submission request. Check your page’s source code for <meta name=”robots” content=”noindex”> or use the URL Inspection Tool to see what Google found during its live test.

The page is blocked by robots.txt

If your robots.txt file disallows Googlebot from crawling the URL or the directory it lives in, Google cannot access the page to index it. Submitting the URL will not override a robots.txt block. Check your robots.txt at yourdomain.com/robots.txt and confirm the page’s path is not listed under Disallow rules.

The content is too thin or duplicated

Google actively filters out pages it considers low-quality, repetitive, or near-duplicate versions of content that already exists in its index. If your page is short, largely templated, or closely mirrors another URL on your site, it may be crawled but not indexed. The URL Inspection Tool will sometimes show this as ‘Crawled, currently not indexed’ in the coverage report.

Canonical tag points to a different URL

A canonical tag signals to Google which URL should be treated as the authoritative version of a page. If your canonical points to a different URL, Google will index that other URL, not the one you submitted. This is common on sites with URL parameters, pagination, or staging-to-production migration issues that were not cleaned up.

Crawl budget limitations

Google allocates a crawl budget to each site based on its authority, server response times, and the quality of pages it has already found. Sites with a large number of low-value pages, slow load times, or frequent crawl errors can exhaust their crawl budget before Google reaches important new content. Keeping your site lean, fast, and technically clean is the long-term fix here.

Best Practices for Submitting URLs to Google

Submitting URLs correctly makes a measurable difference in how quickly and reliably Google indexes your content. These practices keep the process clean and efficient.

Only submit pages worth indexing

Not every page on your site deserves to be in Google’s index. Thank-you pages, account pages, duplicate filtered views, and thin content pages add noise to your crawl budget without contributing any search value. Submit only pages with original, substantive content that you want to appear in search results.

Fix technical issues before submitting

A page submitted with broken links, slow load times, missing canonical tags, or redirect chains is going to have indexing problems regardless of how the submission is made. Run a quick technical check on any page before requesting indexing. The URL Inspection Tool itself surfaces many of these issues in its live test report.

Use HTTPS

Google treats HTTPS as a baseline requirement for trustworthy, rankable pages. If your site still serves pages over HTTP, those pages are at a disadvantage both in indexing priority and in ranking potential. Migrating to HTTPS before submitting URLs removes one more potential barrier.

Do not re-submit the same URL repeatedly

Submitting a URL once adds it to Google’s crawl queue. Submitting it again immediately does not move it higher in that queue or accelerate the process. If a page has not been indexed after a week, the issue is almost certainly a quality or technical problem, not a submission problem. Use the URL Inspection Tool to investigate rather than resubmitting blindly.

Keep pages mobile-friendly

Google uses mobile-first indexing, which means it primarily crawls and indexes the mobile version of your pages. A page that renders poorly on mobile, loads slowly on a phone, or has content differences between mobile and desktop versions will run into indexing and ranking issues. Test your pages with Google’s mobile-friendly test before submitting high-priority URLs.

Wrapping up

The gap between publishing and getting indexed is a real problem. Most of the time it is not a submission problem. It is a quality problem, a technical problem, or a crawl priority problem wearing a submission problem’s mask.

Submit your URLs through Search Console, keep your sitemap updated, link to new pages from existing ones, and make sure every page you submit is technically clean and worth indexing. The URL Inspection Tool will tell you most of what you need to know if something is not moving.

Google indexes what it trusts. Give it a reason to trust your pages first, and the indexing follows.

Tired of buying addons for your premium helpdesk?

Start off with a powerful ticketing system that delivers smooth collaboration right out of the box.

Go Pro!

Frequently Asked Questions

Does submitting a URL to Google guarantee indexing?

No. Submitting a URL adds it to Google’s priority crawl queue, but Google still decides whether to index the page based on its quality, technical health, and relevance. Pages that are thin, duplicated, blocked by robots.txt, or marked noindex will not be indexed regardless of submission.

How long does it take Google to index a submitted URL?

After a manual submission via the URL Inspection Tool, indexing typically happens within a few hours to a few days. In some cases it can take up to a couple of weeks, especially for newer sites with low authority or pages with limited internal links pointing to them.

Is there a limit to how many URLs I can submit per day?

Yes. The URL Inspection Tool has a daily quota for manual indexing requests. The exact limit is not publicly specified by Google, but users typically see quota warnings after submitting a large number of URLs in a short window. For bulk submissions, the sitemap method or Google Indexing API is more appropriate.

Can I submit a URL to Google without Google Search Console?

Without Search Console, your primary options are submitting a sitemap hosted on your server that Googlebot can discover, building internal and external links to the page, and relying on natural crawling. Search Console’s URL Inspection Tool is the most reliable manual method, and setting it up is free.

Why is my page showing ‘Crawled, currently not indexed’ in Search Console?

This status means Google found and crawled the page but chose not to add it to the index. The most common reasons are thin or low-quality content, near-duplicate content that already exists elsewhere in the index, or a canonical conflict where Google determined another URL should be the authoritative version. Improving the content quality and resolving any canonical issues is the recommended approach.

Should I resubmit a URL if it has not been indexed after a week?

Not immediately. If a page has not been indexed after a week, resubmitting it will not change the outcome. The issue is almost always a content quality or technical problem. Use the URL Inspection Tool to run a live test, check the coverage report for specific error reasons, and fix whatever is flagged before submitting again.

What is the difference between crawling and indexing?

Crawling is when Googlebot visits a URL to read its content. Indexing is when Google processes and stores that content in its search database so it can appear in results. A page can be crawled without being indexed if Google determines it does not meet its quality standards or if technical signals prevent inclusion.

The post How to Submit URLs to Google for Indexing (4 Methods) appeared first on Fluent Support.

Error 522 Connection Timed Out: What It Means and How to Fix It - Fluent Support

Sat, 16 May 2026 11:17:44 +0000

When a visitor hits your site and sees “Error 522 Connection Timed Out,” the problem is clear: your website is unreachable. The issue has nothing to do with your visitor’s internet connection.

It has nothing to do with Cloudflare’s infrastructure either. The problem lives on your origin server, and until you fix it, every visitor trying to reach your site lands on that same error page.

In this blog, we will walk through what error 522 actually means, what causes it, and the exact steps to resolve it and prevent it from coming back.

TL;DR

Error 522 is a Cloudflare-specific HTTP status code triggered when the connection between Cloudflare and your origin server times out
The cause is almost always server-side: overload, firewall rules blocking Cloudflare IPs, wrong DNS settings, or disabled KeepAlive
Fixes include whitelisting Cloudflare IPs, verifying your A record, enabling KeepAlive, and checking server resource usage
It is different from error 521 (server actively refusing connections) and error 524 (server connected but responded too slowly)

What Is Error 522?

Error 522 is a Cloudflare-specific HTTP status code. It appears when Cloudflare cannot complete a TCP handshake with your origin web server within its timeout window.

Cloudflare introduced this code to describe one specific failure: the connection between its edge network and your server did not go through.

When a visitor loads your site, their browser talks to Cloudflare first. Cloudflare then reaches out to your origin server to fetch the content. This involves a TCP handshake, a three-step process (SYN, SYN-ACK, ACK) that establishes the connection.

If your server does not return a SYN-ACK within 19 seconds, or fails to acknowledge the resource request within 90 seconds after the connection is established, Cloudflare gives up and returns error 522 to the visitor.

The visitor’s connection to Cloudflare completed successfully. The breakdown happened between Cloudflare and your server.

What causes Error 522?

1. Server overload

This is the most common cause. When your server is maxed out on CPU or RAM during traffic spikes, it cannot accept new incoming connections. Cloudflare sends a request, but the server has no capacity to respond.

Shared hosting plans are especially vulnerable because resources are split across multiple websites on the same machine.

2. Firewall blocking Cloudflare IPs

Cloudflare acts as a reverse proxy. All traffic that reaches your origin server comes from Cloudflare’s IP ranges rather than individual visitors’ addresses.

If your server’s firewall or a security plugin treats those IPs as suspicious and drops the packets, your server never responds. Cloudflare then times out waiting.

3. Incorrect DNS settings

Your Cloudflare DNS must have an A record that points to the correct IP address of your origin server. Server migrations and hosting provider IP changes are common reasons this goes wrong.

When the A record is stale, Cloudflare sends requests to an address that either does not exist or belongs to a different server entirely.

4. KeepAlive disabled

Cloudflare uses persistent TCP connections through KeepAlive headers. When a server closes the connection after every single request, Cloudflare has to re-establish a fresh connection each time.

That repeated overhead increases timeout risk under any meaningful load.

5. Network issues between Cloudflare and your server

Sometimes the server itself is healthy. The failure sits in the network path between Cloudflare’s edge and your hosting provider’s data center.

Packet loss, routing errors, or provider-level congestion can all cause intermittent 522 errors in those situations.

Error 522 vs. Error 521 vs. Error 524

These three Cloudflare errors describe different failure points in the same connection chain.

Error 521: Cloudflare could not connect to your server at all. The server is actively refusing connections, either because it is offline or a firewall rule is explicitly blocking Cloudflare.
Error 522: Cloudflare attempted a TCP connection and received no response within the timeout window. The server is not rejecting requests. It is simply not answering them.
Error 524: Cloudflare established a connection successfully, but the server took too long to send back an HTTP response. The TCP handshake worked. The server just processed the request too slowly.

How to fix Error 522: Step by step

1. Confirm your server is actually online

Start by checking whether the site is down for everyone or just you. Tools like Uptrends or Down for Everyone or Just Me can confirm this in seconds. Also check Cloudflare’s status page to rule out a Cloudflare-side incident before touching anything on your server.

Then try bypassing Cloudflare entirely. Go to your Cloudflare dashboard, open Overview, and under Advanced Actions select Pause Cloudflare on Site. Wait a few minutes, then visit your site directly.

If it loads, your server is running and the issue is in the Cloudflare-to-server path. If the site still does not load, the problem is with your origin server itself.

2. Check server resource usage

Log into your hosting control panel and review CPU, RAM, and I/O usage. Servers that are consistently hitting their limits cannot accept new connections fast enough during traffic surges. Common solutions include removing unused plugins, optimizing database queries, enabling a caching layer, or upgrading to a plan with more resources.

[Insert screenshot example of a hosting panel resource usage dashboard showing CPU and RAM charts]

3. Whitelist Cloudflare IP ranges

This step resolves the majority of persistent 522 errors. Your firewall must allow all Cloudflare IP addresses on ports 80 and 443 for full TCP traffic, not just the initial handshake packet. Cloudflare publishes its full list of IP ranges at cloudflare.com/ips.

For Apache servers, add allow rules to your .htaccess file. For Linux servers with iptables access, add accept rules for each Cloudflare IP range. Most hosting control panels include an IP manager where you can add these ranges directly without touching config files.

4. Verify your cloudflare DNS a record

Go to your Cloudflare dashboard, select your domain, and open the DNS section. Check the A record for your root domain. The IP address in the Content field must match the actual current IP address of your origin server.

Find your server’s IP in your hosting panel under plan details or server information. If there is a mismatch, update the A record in Cloudflare. DNS changes can take up to 24 hours to propagate globally, though most resolve within minutes.

5. Enable KeepAlive on your web server

For Apache, open your httpd.conf or apache2.conf file and confirm KeepAlive On is set. Set KeepAliveTimeout to at least 75 seconds so connections stay open past Cloudflare’s 90-second resource request window.

For Nginx, check nginx.conf for the keepalive_timeout directive and set it to 75s or higher. Restart your web server after making these changes for them to take effect.

6. Review server and application logs

When the steps above do not resolve the error, server logs are the next place to investigate. Check your web server logs (Apache’s error_log, Nginx’s error.log) and your application logs for entries around the time of the error.

A crashing PHP process, a hanging database query, or a misconfigured .htaccess rule can all cause the server to stop responding to new connections without any obvious outward sign.

Does Error 522 affect SEO?

Yes. Search engine crawlers treat 5xx responses as server errors. If Googlebot repeatedly encounters error 522 on your site, it will reduce crawl frequency and may eventually remove affected URLs from the index.

Persistent connection timeouts are among the more damaging server-side issues for search visibility. Resolving the root cause quickly and monitoring uptime proactively will protect your rankings.

How to prevent Error 522 going forward

Set up uptime monitoring so you learn about downtime before your customers do. Review your Cloudflare DNS records after every server migration or hosting provider change.

Audit firewall rules after major security updates and plugin changes, since some updates silently reset IP whitelist configurations. Watch server resource trends over time. CPU usage sitting above 70% consistently is a signal to scale up before a traffic spike forces the issue.

On the support side, site errors like 522 tend to generate a surge of tickets. Having a structured system in place means your team can triage and respond to those reports without things getting chaotic.

Fluent Support gives WordPress-based support teams a proper workflow to manage technical issue reports at scale. For teams running ecommerce support, where uptime directly affects revenue, that structure matters a lot.

Want a system that makes ticket handling this smooth? Fluent Support brings structure and clarity to every request so your team always knows exactly what to do next. See how it works.

Explore Fluent Support Now!

Wrapping up

Error 522 is a server-side problem. Cloudflare surfaces it, but your origin server is the source. The fix almost always traces back to one of four things: server overload, Cloudflare IPs blocked by a firewall, a stale DNS A record, or KeepAlive misconfiguration.

Work through the steps in order. Start with server status, then firewall rules, then DNS, then KeepAlive settings. Most 522 errors resolve at step two or three.

FAQ

Is error 522 always the server owner’s fault?

In nearly all cases, yes. The error points to your origin server environment. Your hosting provider, firewall configuration, or server resource limits are where the fix lives.

Can a DDoS attack cause error 522?

Yes. Cloudflare absorbs most DDoS traffic at the edge, but an extremely large attack can still overwhelm your origin server and cause it to stop responding to connection requests entirely.

Will pausing Cloudflare fix error 522?

Pausing Cloudflare is a diagnostic step. If your site loads after pausing it, the problem is in the Cloudflare-to-server connection path. You still need to resolve the underlying cause before re-enabling Cloudflare.

Does error 522 affect only WordPress sites?

No. Error 522 can occur on any website that routes traffic through Cloudflare, regardless of the CMS or platform. The causes and fixes are the same across setups.

Considering writing with Þorn and Eð characters. Is that annoying to read?

Fri, 15 May 2026 21:20:41 +0000

I’m considering using the þorn & eð characters in my posts, but I do worry that people who aren’t used to seeing them might find their presence annoying or confusing. Like, what it turns away potential readers.

They are very cool characters tho…

Community building at the edge of the Internet

Fri, 15 May 2026 13:37:50 +0000

Why Build a Nostr Community Hub?

The internet has given us incredible tools for connection, yet most community spaces (Facebook groups, Discord servers, Slack workspaces) operate on a fundamental trade-off: you hand over your identity and data in exchange for access. When you leave the platform, you leave behind your connections, your content, and your history. There are good alternatives, but most of them are only available through the Internet and, if they go down, everything the community has achieved goes with it.

Nostr changes this equation entirely. In its paradigm, your identity is a cryptographic keypair that only you control. Your npub (public key) is your username, and your nsec (private key) is your password. There's no "forgot password" email reset because there's no central server holding your account. You can use this identity across dozens of clients, relays, networks, or generate entirely separate identities for different contexts. Want one identity for your local bar community and another for professional networking? Easy. No phone number verification, no email confirmation, no "real name" policy. You and your community define what your identity means.

The problem is that Nostr is very new and thus its pioneers often face a cold-start problem: they generate a key, open a client, connect to a public relay, and are immediately hit with crypto spam and content they didn't sign up for.

A community hub solves this elegantly.

A "Pyramid", but... portable

Pyramid is the name of a Nostr relay software. It acts as the anchor: a clean, moderated space where your community's notes, images, and conversations live.

GitHub - fiatjaf/pyramid: a wondrous furnace of communityzenship backed by a dynamic ladder of socialhood

a wondrous furnace of communityzenship backed by a dynamic ladder of socialhood - fiatjaf/pyramid

GitHubfiatjaf

This is a feature-rich Nostr server that includes:

Group Chats via NIP-29 communities
Collaborative Git repositories via GRASP, for shared documents or community projects
Member-only relay access with whitelist controls, based on invitation from existing members.
Blossom server for binary file uploads—images, video reels, music, PDFs, all stored on your own infrastructure

👀 Behold Dyne.org's pyramid relay:

Dyne Nostr

See yourself in the Invite Tree? Invite a dyne from the channels!

Don't see yourself in it? Ask a dyne in the channels to invite you!

Ask for an invite! 👋

Rumble in the Jumble, community mode

"Jumble" is a Progressive Web App (PWA) that runs a Nostr client.

GitHub - CodyTseng/jumble: A user-friendly Nostr client for exploring relay feeds

A user-friendly Nostr client for exploring relay feeds - CodyTseng/jumble

GitHubCodyTseng

It is shipped with a so-called "Community Mode", which lets you predefine a set of default relays for the people leveraging your build of the PWA. Basically, when someone visits your custom Jumble instance (i.e jumble.your-community-domain.tld), they're immediately connected to your curated relay ecosystem. Not the global firehose.

🪇 Here is dyne.org's community client:

Jumble Ouro

Community-governed fork of Jumble — a Nostr client whose features are voted on and shipped by an AI coding agent.

Jumble Ouro

A cosy digital place

It's cheap

This setup can run on very scarce resources and can easily migrate. It can even be decommissioned with near-zero collateral costs for the people using it: the people never depend on a relay. A person or a bot having to change their Nostr in/out-boxes is the worst-case scenario.

The escape hatch is always open

Once they get the gist of it, people can start exploring other clients, rather than your community's build. Maybe they collaborate on another GRASP (Git over Nostr)? Maybe they want a client for live-streaming? Maybe they want to add the relay accessible in their LBAN (Local Bar's Area Network) in the settings of the client of their choice, because they want to vote for the next Karaoke track? They can always explore communities beyond, with the identity of their choice. Your community hub is just providing a warm, welcoming starting point for a journey through cyberspace. Not an enshitifyable cage.

This setup is ideal for:

Local bars and cafes that want a digital bulletin board and social space for regulars.
Neighborhood communities sharing events, recommendations, and lost cat notices.
Interest groups (book clubs, running crews, gardening collectives) that want a private-ish space without building a whole Discord server
Small businesses looking for a lightweight customer community platform and an easy way to update their website through an app.

How do I use it?

You need an identity. One identity is two things:

An npub. This is a unique public identifier of your identity.
An nsec. This is the secret key. The one that controls it all and must stay secret for as long as it takes.

If you are starting from scratch, create an identity using an app. No internet needed. This is confusing at first, and there are many new words in the authentication flow: "remote signer", "authenticator", "bunker", "passkey"... Essentially, the app is the tool that allows you to "log in to your account". It leverages some cool Planet Dyne adjacent technology from Lugano, code-named NIP-46

Nostr | NIPs

Documentation site for NIPs

Nextra

Super 1337 users will want to look at the CLI tool: nak

# generate a secret key

~> nak key generate
1e90fa2e277921992920dfc4fc9126896e9a3af8ee0fa57fe8dbbf302ac90e68

# generate a public key from the secret one
~> nak key public 1e90fa2e277921992920dfc4fc9126896e9a3af8ee0fa57fe8dbbf302ac90e68
6cf7e488d65abbebd032336101c43d1f2e2a93ccc97856388a28f79e017f9336

GitHub - fiatjaf/nak: a command line tool for doing all things nostr

a command line tool for doing all things nostr. Contribute to fiatjaf/nak development by creating an account on GitHub.

GitHubfiatjaf

At the time of writing, it's unclear if such an app exists on iOS, but on Android, there's this one:

GitHub - greenart7c3/Amber

Contribute to greenart7c3/Amber development by creating an account on GitHub.

GitHubgreenart7c3

Then, to log in, you can point at the QR from a web app and log in.

You can also create and manage identities using extensions for your browser:

Firefox

nos2x-fox – Get this Extension for 🦊 Firefox (en-US)

Download nos2x-fox for Firefox. Nostr Signer Extension (for Firefox)

Diego

Chrome

nos2x - Chrome Web Store

Nostr Signer Extension

Chrome Web Store

But let's talk about wss://relay.dyne.org for a moment!

The dyne.org community can use wss://relay.dyne.org as outbox (write) to save a profile, write notes, share photos and videos, collaborate on Git repositories, and chat in groups. All while everyone maintains full control over their own identity. For inbox (read), thats is incomming stuff, like DMs, replies, reactions to one's content, zaps, etc...) the community can use wss://relay.dyne.org/inbox

You can see your relay settings here: https://nostr.dyne.org/settings/relays

The Pyramid website is useful in some ways. For example, you can set up your NIP-05. This is just a funky way to write your npub. Say your nick is belli, now people can find your npub by searching for belli@relay.dyne.org .

You'll find those settings by clicking your username in the upper-right corner when you are logged in to the relay interface here:

Dyne Nostr

On the Pyramid web UI, you will also find that there is a GRASP server. Read more about GRASP here:

grasp: a simple protocol for decentralized git

Nomadic Group Chats anyone? This client is cool for that:

Nostrord - Decentralized Group Chat · NIP-29 Nostr Client

Nostrord is a NIP-29 client for decentralized group chat on Nostr. Built with Kotlin Multiplatform (KMP) and Compose. Relay-enforced moderation, censorship-resistant communities, cryptographic identity. No servers, no sign-up, no lock-in.

The Nostrord TeamThe Nostrord Team

And a blossom server to store your pictures and videos! You can store up to 256Mb of goodness on there. Blossom is a wonderful concept for portable binary data. Read about it here, or just try out a client that manages your blossoms here:

bouquet

Learn more!

The UX of nostr is wild; there's an increase in interest among builders, fueling all sorts of client development. Rumble in the Jungle, essentially! If you tested the Dyne.org community build of Jumble, you might have noticed that one relay in the network is Spatia-arcana.com. They've written extensively to help onboard new people. I urge you to consult the manual they're developing here:

The Pyramid Community Relay

* Getting Started with Pyramid * Pyramid’s Features, pt 1 (Home, Main, and Subrelays) * Pyramid’s Features, pt 2 (Media, Chats, and More) * Managing Your Pyramid Community * Benefits of Pyramid Membership * Troubleshooting Your Pyramid

Spatia NostraD.

Here's some very useful high-level information about Nostr in general.

Nostr - Notes and Other Stuff Transmitted by Relays

Notes and Other Stuff Transmitted by Relays

Nostr is more than a social protocol; it's a decentralized form of Digital Identity, a topic dear and close to the heart of Planet Dyne.

Privacy in EUDI

Until process isolation is granted for every execution of zero-knowledge algorithms, privacy-preserving technology won’t protect us from mega-corporations spying on us.

News From DyneJaromil

..so many questions.

That's ok. We can't answer them all today. But feel free to drop a comment below or come say hi in the channels! We'll figure it out together!

Tune in to the discussion 💬

(These services are bridged: join your favorite and reach them all)

🗨️ IRC
🗨️ Matrix
🗨️ Telegram
🗨️ Discord

Help dyne.org stay focused on hacking the planet!

🥰 Donate 💸

🪙 Bitcoins: bc1qz9wz2f9swcefra2tfrhk4fx49evqsv03m9nx4l
☕ Ko-Fi
🍴 Github.com
🧁 LiberaPay
🍥 Patreon.com

Follow Dyne.org 🗞️

Social Media everywhere!

Two-Minute _Iolanthe_

Fri, 15 May 2026 06:55:38 +0000

The other day I came across Connie Kleinjans’ page of “two-minute versions” of G&S shows. She’s got two versions of Gondoliers and one each of Iolanthe and Ruddigore. The technique is the same as in blackout poetry: take the whole work and black out all but the most important and/or funniest bits.

Kleinjans’ short scripts are funny in their own rights, but I wanted audio versions; so I made one. Presenting “Two-Minute Iolanthe in five minutes”.

The original recording I “blacked out” for this video is a TV broadcast of a 1976 production at the Sydney Opera House featuring Rosemary Gunn (Iolanthe), Heather Begg (Fairy Queen), Dennis Olsen (the Lord Chancellor), June Bronhill (Phyllis), Lyndon Terracini (Strephon), Graeme Ewer (Mountararat), Ronald Maconaghie (Tolloller), and Alan Light (Private Willis). This is a low-quality VHS rip of an excellent performance.

The VHS rip on YouTube is missing a chunk of the finale, which prompted some alterations to the script; I made a few other alterations for pacing. Even after those cuts, this “two-minute” Iolanthe is almost five minutes long; watch at 2.3x speed for a true two-minute experience.

To create the video, I used ffmpeg to clip and concat the snippets. When concatenating 169 tiny snippets, your biggest problem will be “timestamp drift” between the audio and video channels. I spent a long time cajoling ChatGPT into giving me new permutations of command-line switches to try before finally settling on the programs linked below.

Step 1 was to get the original video (2.4 gigabytes, saved as input.mkv):

brew install ffmpeg yt-dlp
yt-dlp 'https://www.youtube.com/watch?v=DLYSZN2IqeU'

Step 2 was to snip the constituent bits via ffmpeg commands. I factored out the common arguments into environment variables so I didn’t have to keep typing or tabbing over them.

PREFIX="-y"
SUFFIX="-i input.mkv -c:v libx264 -preset veryfast -crf 20 -c:a aac"
ffmpeg $PREFIX -ss 00:07:07.2 -to 00:07:10.5 $SUFFIX part001.mkv
ffmpeg $PREFIX -ss 00:07:45.0 -to 00:07:48.6 $SUFFIX part002.mkv
~~~~

ffmpeg turns out to be supremely sensitive to whether you put the input (-i input.mkv) before, or after, the -ss and -to switches. With -i input.mkv as part of the SUFFIX, my whole script.txt runs in 61 seconds; as part of the PREFIX, it takes 98 minutes.

To concatenate all those clips and re-encode a “preview” video, we can do this:

rm list.txt
for i in part*.mkv ; do echo "file $i" >>list.txt ; done
ffmpeg -y -f concat -safe 0 -i list.txt \
  -c:v libx264 -crf 20 -preset veryfast -c:a aac -ar 48000 output.mp4

Step 3 was to fight timestamp desynchronization. My solution here was generated entirely by blind fumbling and incantations, with input from ChatGPT. It seems that there are basically two ways to get ffmpeg to “supercut” a video as we’re doing here: either clip out the clips into temporary files and then concatenate all those little files (as we did above — this way causes a lot of drift), or do one big “filter” operation to take just the frames you care about in a single ffmpeg invocation. That looks like this, except with 169 clips instead of 3:

ffmpeg -y -i input.mkv -filter_complex \
 "[0:v]trim=start=427.2:end=430.5,setpts=PTS-STARTPTS[v0];
  [0:a]atrim=start=427.2:end=430.5,asetpts=PTS-STARTPTS[a0];
  [0:v]trim=start=465.0:end=468.6,setpts=PTS-STARTPTS[v1];
  [0:a]atrim=start=465.0:end=468.6,asetpts=PTS-STARTPTS[a1];
  [0:v]trim=start=616.5:end=618.7,setpts=PTS-STARTPTS[v2];
  [0:a]atrim=start=616.5:end=618.7,asetpts=PTS-STARTPTS[a2];
  [v0][a0][v1][a1][v2][a2]concat=n=3:v=1:a=1[v][a]"
  -map [v] -map [a] \
  -c:v libx264 -crf 20 -preset veryfast \
  -c:a aac -b:a 192k -ar 48000 \
  output.mp4

That’s horribly slow; it seems to have quadratic behavior as the number of clips increases. Even worse is trying to use the non-“complex” filter options -vf and -af:

ffmpeg -y -i input.mkv \
  -vf "select=between(t,427.2,430.5)+between(t,465.0,468.6)+between(t,616.5,618.7),setpts=N/FRAME_RATE/TB" \
  -af "aselect=between(t,427.2,430.5)+between(t,465.0,468.6)+between(t,616.5,618.7),asetpts=N/SR/TB" \
  -c:v libx264 -crf 20 -preset veryfast \
  -c:a aac -b:a 192k -ar 48000 \
  output.mp4

That just makes ffmpeg run out of memory before you’ve even hit 50 clips. So I ended up using a hybrid approach: I used -filter_complex to produce nine intermediate concatenations of 20 clips at a time, and then used

ffmpeg -y -f concat -i list.txt -c copy output.mp4

to paste those nine files together. I’ve saved my programs for posterity: script.txt runs as a Bash script (in just over 1 minute on my machine) to create that “draft preview” video output; its textual contents also serve as input to script.py, which creates the final product (in about 9 minutes) using the two-level -filter_complex approach. The finished output.mp4 is about 42 megabytes in size.

Amazonbot is finally respecting robots.txt - Xe Iaso

Fri, 15 May 2026 04:34:22 +0000

Amazonbot is finally respecting robots.txt

Published on 2026-05-14, 239 words, 1 minutes to read

Thanks for giving me a viable business model Amazon!

I just got an email from Amazon saying they're finally going to respect robots.txt. Here's the verbatim email I got:

We are writing to inform you that starting Monday, June 15, 2026, crawl preferences for Amazonbot will be managed solely through the industry-standard directives. This gives you direct, ongoing control over how Amazonbot accesses your site, rather than relying on manual requests. If you do not implement robots.txt directives by that date, Amazonbot will follow standard web crawling practices when accessing your site.

How to maintain your current preferences: The robots.txt protocol allows you to control Amazonbot’saccess at the page-, directory-, or site-level and update your preferences at any time. Please find detailed information on Amazonbots approach to these directives here: https://developer.amazon.com/amazonbot.

Best,

Amazon Publisher Support

amazonbot@amazon.com

Get Outlook for Mac

Numa

Amazing, they even kept the "sent from my iPhone" message proving they sent it from Outlook for Mac. Looking at the email headers it has a bunch of Exchange-specific headers so it's probably actually from Outlook for Mac. This timeline is absolutely wild.

This makes me feel kinda weird because Amazon's scraper is why Anubis exists.

I'm gonna make sure to merge these robots.txt changes into Anubis if they aren't already there.

Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.

Tags:

Browsers Treat Big Sites Differently — Den Odell

Thu, 14 May 2026 18:05:10 +0000

Some browsers ship code that checks which domain you’re visiting and changes how the page renders based on it.

Yup, you read that right. If site == X, do Y.

TikTok gets special treatment. So does Netflix. So does Instagram.
And so does SeatGuru.

Safari and Firefox both do this. Chrome doesn’t.
That tells us something interesting.

The source code is right there if you want to look. These are literal domain checks baked into browser rendering engines that say things like “if the user is on this domain, render this differently” or “if they’re on that domain, handle that API call differently.” It’s not a bug. It’s a feature, and it ships to billions of devices.

Firefox’s about:compat

If you open Firefox and type about:compat in the address bar, you’ll see a list of site-specific interventions complete with toggle switches. Each one is a targeted fix for a specific website, and you can turn them off and watch sites break.

Firefox’s WebCompat system injects custom CSS and JavaScript into specific domains, changes user agent strings for sites that sniff browsers incorrectly, and papers over bugs that would otherwise make the web feel broken. The interventions are tracked in Mozilla’s Bugzilla, complete with bug reports and sometimes failed outreach attempts to the sites in question.

Safari’s “quirks”

Safari’s WebKit engine calls them “quirks,” and the file Quirks.cpp is publicly available on GitHub. Reading through it is an education in how the web actually works. Here’s one comment from the code:

Facebook, X (twitter), and Reddit will naively pause a <video> element that has scrolled out of the viewport, regardless of whether that element is currently in PiP mode.

So the browser detects when you’re on facebook.com, x.com, or reddit.com and changes how it handles Picture-in-Picture video. These companies wrote broken video code, and rather than wait for them to fix it, the browser shipped a workaround to every user. Here’s another comment:

FIXME: Remove this quirk if seatguru decides to adjust their site.

Someone added domain-specific rendering code for SeatGuru, and the comment implies outreach was attempted. SeatGuru didn’t fix their site, so the browser fixed it for them.

The commit history is a fascinating read. In just the last few months: Zillow’s floorplan images weren’t centering, TikTok was showing “please upgrade your browser” messages, Instagram Reels were resizing erratically during playback, Netflix’s “Episodes and Info” button was dismissing popovers incorrectly, Twitch was pausing PiP videos when you switched tabs, and Amazon Prime Video wasn’t letting Safari users watch at all. Each one got a domain-specific fix shipped to every single user.

Chrome Is Different

The quirks files aren’t just fixing broken sites; they’re often compensating for Chrome’s control over what “working” means in the first place.

The pattern goes like this: Chrome ships a feature, developers use it because Chrome dominates the market, and other browsers scramble to either implement the feature or add site-specific quirks to paper over the difference. By the time Safari or Firefox catches up, the quirk has already shipped to millions of users.

WebKit’s source code includes user agent overrides that make Safari pretend to be Chrome for specific sites like Amazon’s video pages and various streaming services. These sites sniff for Chrome and serve degraded experiences to everyone else, so rather than let Safari users suffer, WebKit lies about what browser it is. From the current Quirks.cpp source:

auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;

Safari literally ships with a fake Chrome user agent string, ready to deploy when sites refuse to work otherwise. Firefox does the same thing, and many of its about:compat interventions are user agent spoofs telling sites “yes, I’m Chrome” because those sites actively block or break on non-Chrome browsers. The Mozilla wiki explains that some sites “block access completely, display a different design, or provide different functionality” based on browser detection. So Firefox ships workarounds.

This creates a feedback loop. Developers build for Chrome because Chrome dominates. Their sites work best in Chrome. Users who hit bugs elsewhere blame the browser, not the site, so they switch to Chrome, reinforcing its dominance.

It Goes Deep

These aren’t just cosmetic tweaks. Browsers change fundamental behavior based on your domain, including scrolling behavior, touch event handling, viewport calculations, and image MIME type handling. The list in WebKit alone runs to thousands of lines.

Here’s one about simulated mouse events:

When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.

The browser checks if you’re on Amazon and changes how touch-to-mouse event translation works for their product zoom feature. Amazon’s site assumes certain event behavior that Safari doesn’t provide by default, so Safari provides it anyway, but only for Amazon.

There are quirks for storage access, scrollbar rendering, autocorrection behavior, and zoom handling. Each one is behind a domain check, and each one is compiled into the browser executable.

Chrome Doesn’t Need a Quirks File

You might have noticed something. I’ve shown you Firefox’s about:compat and WebKit’s Quirks.cpp, but where’s Chrome’s equivalent?

Chrome doesn’t really need one, and not necessarily because Chrome is better engineered. The web is already built for Chrome. When over 80% of users browse with Chromium-based browsers, developers build for Chrome first. If a site works in Chrome, it ships. If it breaks in Safari or Firefox, they decide, knowingly or otherwise, that it’s less of a problem.

Chrome doesn’t add quirks; it sets the agenda. When Chrome changes how something works, sites update to match, and other browsers follow or break.

This is the asymmetry that runs through the modern web. When a site breaks in Safari, WebKit engineers add a quirk. When Chrome wants to change how the web works, Chrome just changes it and everyone else adapts. Chrome doesn’t need quirks because Chrome’s interpretation of web standards is the version that everyone else works to.

This isn’t done maliciously and it isn’t entirely Google’s fault; really it’s the natural consequence of market dominance. Browser engineers will tell you the specs themselves are actually well-defined now. The HTML5 “living specification” approach solved the chaos of the IE/Netscape era by making specs match reality. The problem is that developers rely on unspecified implementation details, then blame non-compliant browsers when those details differ.

While that may be true, it doesn’t change the outcome. When Chrome is the implementation everyone targets, Chrome’s unspecified details become the de facto spec. The same thing happened with Internet Explorer in the 2000s. When developers built for IE, sites broke elsewhere, and standards compliance became secondary to just making it “work in IE.” We spent years digging out of that hole.

A decade ago, the hope was that browser quirks would eventually disappear as the web became more standards-compliant. You could argue they did, but not for the reason anyone expected: the quirks didn’t go away, they just moved to browsers that aren’t Chrome.

Easier To Fix Than To Wait

You might wonder why browser vendors don’t just contact the offending sites and ask them to fix their code. Sometimes they do, and there’s even a field in source code comments linking to outreach efforts, but consider the economics of that.

A browser vendor’s job is to make the web work for users, and if a popular site is broken in their main browser yet works in Chrome, users blame the browser. Filing a bug with a third party and waiting weeks or months for a fix that may never come is a losing proposition when you can ship a five-line workaround tomorrow.

There’s also the question of who you’d even contact. The developer who wrote the broken code might have left the company years ago, the team that owns that endpoint might not know it’s their responsibility, and the site might be in maintenance mode receiving security patches but nothing else. From the browser’s perspective, the choice is simple: fix it now, invisibly, and save everyone the trouble.

A WebKit engineer wrote a blog post about removing a quirk for FlightAware. The site was comparing CSS transform matrix strings, but the CSS spec had changed how browsers should serialize the values, and the browser became compliant, FlightAware broke, and engineers added domain-specific code to fix it. Outreach eventually worked, FlightAware fixed their code, and the quirk was removed. But for months, Safari users had a working experience only because someone wrote an if statement in the browser checking for flightaware.com.

Check Yourself

Your site might be getting special rendering treatment and you might not be aware of it. That quirk you’re benefiting from doesn’t show up in your error logs, and there’s no console warning that says “this browser is working around your mistakes.” The fix is invisible by design.

If you test mostly in Chrome, you’re especially exposed. Your site might work perfectly not because you wrote good code but because Chrome’s behavior aligns with your assumptions. Other browsers will have to choose between letting your site break for their users or adding you to their quirks file.

Open your site in Firefox and Safari. Not occasionally, not before a big launch, regularly. The quirks files exist because developers didn’t do that.

If you find your domain in one, consider auditing whatever it was they worked around. Not because you have to (after all, the web kept working without your intervention) but because somewhere an engineer at a browser you don’t use solved a problem you didn’t know you had.

The Web We Want vs The One We Have

The specs are the map, but the quirks lists are the messy terrain.

Standards were supposed to eliminate browser-specific code. We dug ourselves out of the IE era, celebrated, and then built exactly the same hole again around a different browser. Only now the browser-specific code lives in the browsers that aren’t dominant, patching over a web built for the one that is.

Sites I’ve worked on are in these files. Yours might be too.
And the lists are getting longer.

The

Thu, 14 May 2026 18:05:10 +0000

One of the few traps of the web is how the <noscript> element doesn't provides the right behavior.

Definition: The <noscript> element provides alternate content when JavaScript is entirely toggled off or entirely unsupported.
Sources:

HTML4 § 18.3.1 The NOSCRIPT element with ignoring non-JavaScript in <script> (W3C gives Tcl as example, I'd more point to JScript and VBScript, both of which are thankfully gone)
WHATWG HTML (multipage) § The noscript element

While the way to obtain the right behavior is to have a generic textual element being updated/deleted by your own script using the DOM APIs. You could also make the scripts so optional for you to not need to provide a failure message, but that's not the right method when the scripts are needed for actually using the webpage.

And should be noted that WHATWG HTML contains a similar recommendation to the latter method:

The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly, […]

Because the problem is, JavaScript can fail to load in several ways. Here's a non-exhaustive list of cases:

Blocked domains/URLs, think adblockers/anti-viruses or corporate firewalls
Blocked browsers/users, think hosting-side firewall (at any of the IP/TCP/HTTP/… level of encapsulation) which can be legitimate, over-zealous, or accidental
Basic connectivity issues, after all browsing using mobile data is usual, HTTPS configurations still routinely presents expired certificates, BGP/DNS/… still fails
Unsupported APIs or even language syntax, either due to a browser not supporting bleeding edge features or non-portable features
Badly restored website backup or incomplete one
Badly deployed website update, think HTML updated before JavaScript or even an incomplete deployment
Part of the hosting infrastructure being down or overloaded
Limits from the hoster, like rate-limits or limits on total bandwidth

I see most of the above on a regular basis, about multiple times per week to few times a month, and I tend to browse simple websites. And that's without counting the various ways scripts tend to fail at properly handling errors.

Comment désactiver l’IA dans Chrome pour retirer le modèle de 4 Go installé sans autorisation ?