Ahora es más seguro poner Cloudflare delante de Shopify: qué arregló O2O y qué siguen significando las advertencias.

Inicio rápido: haz esto en tu tienda

Si vienes por los pasos, aquí están. Toda la configuración se reduce a un CNAME proxiado en Cloudflare, el mismo dominio conectado en Shopify y un interruptor de HTTPS que se deja en paz. El resto del artículo explica por qué importa cada paso y cómo confirmar que quedó bien, pero esta es la configuración completa.

Si prefieres verlo: Field Notes: Cloudflare in front of Shopify cubre lo mismo en tres minutos, con transcripción completa en la página.

Paso 1 en el panel de Cloudflare: ambos registros son CNAME a shops.myshopify.com con el Proxy status en Proxied.

Los valores de clawmart.digital que aparecen a lo largo de este artículo provienen de una tienda de pruebas real que mantenemos sobre una instancia de Shopify plenamente funcional, no de una maqueta. Cada captura, registro y prueba de abajo sale de esa tienda.

La advertencia sobre una tienda que funciona

Tu dominio de Shopify aparece como conectado, el checkout funciona y el candado SSL está en su sitio. Justo debajo de ese estado en verde hay una advertencia ámbar que dice que tu dominio tiene un proxy de Cloudflare, algo que Shopify no admite. Las dos cosas son ciertas a la vez, y en esa contradicción es donde se atasca la mayoría de comerciantes.

Este es uno de los mensajes más confusos de la infraestructura de ecommerce, porque no es falso y tampoco es del todo exacto. Durante años, poner Cloudflare delante de Shopify fue una idea genuinamente mala que rompía tiendas de una forma concreta y predecible. Luego Cloudflare lanzó una función de enrutamiento que arregló exactamente aquello que se rompía, y aun así Shopify te sigue diciendo que no lo hagas. Ese hueco, entre una solución que funciona y un proveedor que no la respalda, es donde vive la preocupación de si tu tienda está a punto de romperse.

Así que esta es la versión práctica: qué se rompía de verdad, qué arregló O2O, el único ajuste que todavía puede tumbarte el sitio si se te pasa, y cómo decidir si algo de esto le conviene a tu tienda.

Por qué antes se rompía: dos nubes naranjas

Cloudflare muestra un dominio proxiado como una nube naranja. El tráfico hacia ese dominio pasa por la red de Cloudflare antes de llegar a tu origen. La pega en Shopify es que Shopify funciona sobre Cloudflare. Así que cuando apuntas tu dominio con la nube naranja a Shopify, la petición llega a Cloudflare con dos zonas que la reclaman: la tuya y la de Shopify. Dos nubes naranjas, apiladas.

Históricamente, Cloudflare no podía determinar de forma fiable qué zona debía quedarse con esa petición, así que resolvía al sitio equivocado o entraba en bucle. El resultado era una tienda que funcionaba a medias y fallaba de maneras difíciles de reproducir.

El filo más peligroso era SSL. Shopify aprovisiona y renueva tu certificado a través de Let's Encrypt, y Let's Encrypt comprueba que el dominio es tuyo con un desafío ACME servido en una ruta concreta:

Si un proxy delante de Shopify intercepta, cachea o redirige esa ruta, el desafío nunca se completa. Sin desafío completado no hay certificado. Y como los certificados se renuevan según un calendario, esto solía fallar en silencio: la tienda funcionaba perfectamente con el certificado existente durante semanas y luego quedaba insegura el día en que caducaba. Por eso el consejo antiguo era una sola línea tajante: pon la nube en gris, solo DNS, saca el proxy de Cloudflare del camino.

Qué cambió Orange-to-Orange

Orange-to-Orange, u O2O, es la respuesta de Cloudflare al problema de las dos zonas, y forma parte de un producto llamado Cloudflare for SaaS. Cloudflare abrió ese producto a todos sus clientes en 2021, con disponibilidad general aquel octubre, así que O2O es una ruta asentada, con años a sus espaldas, no un experimento reciente. El mecanismo es sencillo: cuando tu zona proxiada apunta un CNAME a un servicio que también es cliente de Cloudflare for SaaS, Cloudflare reconoce el destino y deja de tratar a las dos zonas como una colisión. Enruta la petición primero por tu zona y después por la del proveedor, en un orden definido, y el doble proxy se convierte en un relevo.

No tienes que creerte a ciegas que O2O se activó. Crea el CNAME con el proxy encendido y Cloudflare pone un pequeño icono de Shopify junto al registro. Ese icono es la detección confirmando que sabe adónde va el tráfico. Cloudflare además hace tareas específicas del proveedor en segundo plano, entre ellas desactivar Workers y Snippets en la ruta /checkout, de modo que nada de lo que ejecutes en el edge pueda interferir con el pago.

Ese registro se añade en el panel de Cloudflare, en DNS y luego Records. Haz clic en Add record, pon el Type en CNAME, el Target en shops.myshopify.com y el Proxy status en Proxied para que la nube se vuelva naranja. El icono de Shopify aparece junto al registro en cuanto Cloudflare reconoce el destino como uno de sus propios clientes de SaaS.

Cómo manejar la única excepción: SSL

O2O arregló la colisión de enrutamiento. No arregló SSL, porque SSL nunca fue realmente un problema de enrutamiento. Era un proxy tocando la única ruta que Shopify usa para renovar certificados. En una tienda bien montada casi todo esto funciona ya solo, así que lo útil es saber qué es automático y luego repasar la lista corta de lo que no lo es.

Qué ocurre ahora de forma automática

Tu tienda lleva dos certificados, y los dos se renuevan sin ti. Como el dominio está proxiado, el certificado que ven los visitantes es el propio certificado de edge de Cloudflare, que Cloudflare valida por DNS y renueva por su cuenta, así que la ruta ACME nunca lo toca. Detrás, Shopify mantiene un certificado de origen aparte para el tramo entre Cloudflare y Shopify, renovado a través de Let's Encrypt, y tu modo de cifrado Full está pensado para confiar en él. Shopify también hace la elevación de HTTP a HTTPS en su propio origen, así que los visitantes aterrizan en una conexión segura, mueva Cloudflare un dedo o no.

Ese certificado de origen se renueva mediante ACME, el intercambio automatizado que usa Let's Encrypt para confirmar que controlas el dominio. Pide a lo que sea que responda por tu dominio que sirva un token de un solo uso en la ruta de arriba, por HTTP sin cifrar, y Shopify gestiona todo el intercambio en segundo plano. Por eso nunca piensas en ello. La configuración se mantiene sana exactamente mientras esa ruta siga siendo accesible.

Lo único que lo rompe

Toda esa renovación automática depende de que un ajuste de Cloudflare siga desactivado, y en muchas configuraciones viene activado de fábrica.

Así que la solución consiste sobre todo en no activar ese interruptor y dejar que la redirección de origen de Shopify haga la elevación que ya realiza. Si quieres que Cloudflare imponga HTTPS también en su propio edge, usa una regla de redirección que se salte la ruta del desafío, nunca Always Use HTTPS.

Qué conviene comprobar

Todo lo que viene ahora vive en el panel de Cloudflare. Inicia sesión en dash.cloudflare.com, elige tu cuenta y haz clic en el dominio para abrir su zona. Cada punto es una ruta en la barra lateral izquierda de esa zona.

Hay un vecino en esa página de Edge Certificates que despista a mucha gente: Automatic HTTPS Rewrites se puede dejar activado sin problema. Solo reescribe enlaces de recursos http a https para evitar avisos de contenido mixto, que no tiene nada que ver con Always Use HTTPS forzando una redirección de página completa. Opportunistic Encryption y TLS 1.3 también pueden quedarse activados. Always Use HTTPS es el único interruptor de esa pantalla que tiene que seguir apagado.

Luego confírmalo desde fuera, sin esperar a que falle una renovación. Pide la ruta del desafío por HTTP sin cifrar y lee la respuesta:

curl -sI http://clawmart.digital/.well-known/acme-challenge/test

Llegar a Shopify es la victoria, y un 404 para el token inventado es exactamente lo correcto. Una redirección 301 o 308 a HTTPS significa que Always Use HTTPS o una regla general siguen tragándose la ruta. Después de eso, revisa el estado del SSL en Settings → Domains de tu admin de Shopify y, durante las semanas siguientes, observa cómo la fecha de caducidad del certificado de origen avanza sola. Un certificado que se renueva sin que nadie lo toque es la señal de que la configuración aguanta.

Vuelve a ejecutar esa prueba después de cualquier cambio en tu DNS o en los ajustes de Cloudflare, no solo al montarlo. Hardeep, usuario de la Shopify Community, lo planteó en el hilo sobre este artículo, y coincide con la forma en que estas configuraciones fallan de verdad. La configuración era correcta el primer día, alguien editó una regla o un registro meses después, y nadie volvió a comprobar la ruta del desafío hasta que un certificado no se renovó en silencio.

Vale la pena nombrar una trampa con claridad: que un certificado aparezca aprovisionado hoy te dice que el actual se emitió, no que la próxima renovación vaya a salir bien. Los certificados de Let's Encrypt se renuevan en un ciclo de unos sesenta a noventa días, así que una tienda con aspecto de estar perfectamente sana puede ser sencillamente una que todavía no ha llegado a su fecha de renovación. Eso, sumado a que muchas tiendas nunca llegaron a activar Always Use HTTPS, explica que muchas lleven meses así sin un solo tropiezo, y que el fallo, cuando llega, resulte desconcertante. No cambió nada, salvo un certificado que en silencio no se renovó.

Dale el peso justo. Esto es un seguro barato contra un fallo poco frecuente pero silencioso, no una señal de que tu tienda vaya a romperse. Haz la configuración de dos minutos, ejecuta la prueba y habrás cerrado el único hueco del momento de la renovación que es genuinamente difícil de detectar.

Shopify sigue sin dar el visto bueno a esto, porque…

La documentación de Shopify ya no habla en abstracto de "proxies" en general. Nombra O2O directamente:

"Las configuraciones de proxy de Cloudflare, incluida O2O, no son compatibles con Shopify. Aunque tu tienda parezca funcionar correctamente, esta configuración podría romperse en cualquier momento."

No es una advertencia desfasada sobre un problema ya resuelto. Es una postura actual y deliberada, y dos de las razones que hay detrás siguen en pie incluso después de O2O:

La documentación de Shopify añade una tercera razón, la detección de bots, argumentando que el tráfico que pasa por Cloudflare le llega con atributos de petición alterados. En la práctica es la más floja de las tres: Cloudflare opera una de las mayores redes de gestión de bots que existen, así que la mayoría de tiendas gana mucho más filtrado de bots en el edge del que Shopify pierde en señal. Es el único punto de la lista de Shopify en el que el proxy tiene más probabilidades de ayudar que de perjudicar.

¿Es la advertencia demasiado dura?

Un poco, y se entiende. El panel marca una tienda conectada y funcionando con una "Issue" ámbar y la frase seca "not supported", que pesa más que los modos de fallo reales, casi todos evitables con una configuración correcta. Un comerciante lee "Issue" y oye "tu tienda está a punto de romperse", cuando lo que Shopify quiere decir se parece más a "no vamos a responder por esto".

Pero "no compatible" no es "no funciona", y la distinción importa. Significa que Shopify no va a garantizar, depurar ni asumir responsabilidad por el comportamiento de una capa que no controla. Para una plataforma que se hace cargo de tu checkout y de tu disponibilidad, esa es una línea razonable, aunque el aviso la trace de forma brusca. La marca te dice que Shopify no va a respaldar la configuración. No te dice que la configuración esté fallando.

Hay muchas tiendas Shopify funcionando así

No tienes que fiarte de la palabra de una sola tienda de pruebas. Un proxy de Cloudflare delante de Shopify no es una configuración marginal: muchas marcas consolidadas lo usan en producción, todos los días. Los nombres de abajo son ejemplos reales que verificamos a mano, cada uno sirviendo actualmente su escaparate a través de un proxy de Cloudflare con Shopify detrás.

Verificado en julio de 2026 solicitando cada dominio y confirmando una respuesta de proxy de Cloudflare junto con marcadores de escaparate de Shopify. La configuración de una tienda puede cambiar en cualquier momento, así que tómalo como una foto fija, no como un respaldo por parte de las marcas listadas.

Qué te da el edge que Shopify no te da

Shopify ya incluye un CDN, certificados SSL y protección DDoS en todos los planes, como también señaló Hardeep en el hilo de la comunidad. El proxy no es lo que hace que tu tienda sea rápida, esté cifrada o pueda absorber una avalancha, y si eso era lo que buscabas, ya lo tienes. Lo que viene ahora es el conjunto más estrecho de cosas que Shopify no te da.

El motivo para aceptar el compromiso no es el proxy en sí. Es la capa que el proxy pone delante de tu tienda, un edge programable que Shopify no te expone. Tres capacidades son las que más importan, y la tercera es una que la mayoría de tiendas no llega a ver nunca.

Nada de eso viene con un plan de Shopify, porque nada de eso vive dentro de Shopify. Vive un salto antes, en el edge, que es toda la razón por la que un comerciante asumiría un proxy no compatible en primer lugar.

Un matiz: el cacheo en el edge no es automático. Cloudflare puede guardar archivos estáticos como hojas de estilo e imágenes en su edge y servirlos desde un servidor cercano en lugar de pedírselos a Shopify en cada visita, pero una tienda Shopify proxiada no cachea por su cuenta, y una regla de caché predeterminada o mal delimitada puede anularlo del todo, de forma que archivos marcados como cacheables durante un año pasan de largo sin tocarse. La propia red de Shopify mantiene el escaparate rápido de todos modos, así que trata el cacheo en el edge como un extra de velocidad al que te apuntas. El modo de cifrado que evita los viejos problemas de SSL se confirma en las configuraciones de SSL/TLS, la misma pantalla del botón Configure que veíamos antes; el cacheo se configura en su propia sección, así que vale la pena revisar las dos mientras estás en el panel, ya que el cacheo es el ajuste que con más probabilidad está dejando velocidad sobre la mesa.

Sobre qué te va a advertir un desarrollador

Un buen desarrollador no dará esto por bueno sin preguntas, y las preguntas son justas. Ninguna es motivo para evitar la configuración, pero cada una merece confirmarse en tu propia tienda en lugar de darla por hecha. Eso no es trabajo extra: son las mismas pruebas que harías después de cualquier cambio de infraestructura, y forman parte de mantener una tienda sana. Nosotros probamos las dos cosas siguientes en la tienda que gestionamos, y tú deberías hacerlo también.

Latencia en el relevo

La primera pregunta es la velocidad: ¿pasar por tu zona de Cloudflare antes que por la de Shopify añade tiempo perceptible? No debería, porque las dos zonas ya están sobre la misma red de Cloudflare, así que el relevo ocurre dentro de esa red y no por la internet abierta. Lo medimos en clawmart.digital, la tienda de pruebas proxiada, frente a endpoints de Shopify myshopify.com sin proxy desde la misma máquina. La tienda proxiada respondió en el edge en unos 150 a 200 milisegundos, la misma banda que los endpoints de Shopify sin proxy que había al lado. El salto extra se perdió dentro de la variación normal entre ejecuciones.

Cuando una tienda Shopify proxiada sí se nota lenta, la causa casi siempre es un tema pesado o una app de terceros lenta, no el proxy. Mide antes de culpar al edge. El tiempo hasta el primer byte, ejecutado varias veces desde una misma ubicación, es la lectura más rápida:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://clawmart.digital/

Compáralo con una referencia de nube gris (solo DNS), o con tu dirección myshopify.com, o con una ejecución de WebPageTest. Unos pocos milisegundos de diferencia significan que el proxy no es tu cuello de botella. Cientos de milisegundos significan que lo son el tema y la pila de apps, y ahí es donde hay que invertir el tiempo: adelgazar el tema, quitar apps que ya no usas y arreglar cómo se cargan las imágenes moverá la cifra mucho más que cualquier cosa que configures en el edge.

Apps en el checkout

La segunda pregunta es el checkout: ¿interferirá el proxy con las apps de Checkout Extensibility, con el pago o con los scripts que se ejecutan en el paso más importante? Por diseño no debería. El enrutamiento O2O de Cloudflare desactiva Workers y Snippets en la ruta /checkout precisamente para que nada de lo que ejecutes en el edge pueda tocar el pago. En nuestras pruebas, ninguna de las apps populares de Checkout Extensibility se ha comportado mal con esta configuración. Esa es nuestra experiencia, no una garantía para todas las apps del mercado, así que ejecuta siempre un checkout completo por tu cuenta.

Pasa un pedido real con tus apps activas: confirma que los descuentos, la lógica de envío, los upsells y cualquier extensión de post-compra se disparan igual que sin el proxy, y que el pedido llega a Shopify con los atributos que esperas. Si una app va a comportarse mal, sale aquí, en tu pedido de prueba, mucho antes de que un cliente se lo encuentre.

¿Seguirán funcionando tus funciones de Shopify?

Esta es la pregunta que hacen los comerciantes justo antes de echarse atrás: si Cloudflare está delante, ¿siguen comportándose igual las cosas que gestiono dentro de Shopify? La que más ansiedad genera son las redirecciones de URL, porque se gestionan en el admin de Shopify, importan para el SEO y no resulta obvio si un proxy delante las va a cachear, reescribir o tragarse.

Así que lo probamos en la tienda proxiada en lugar de razonar sobre ello. Creamos una 301 en el admin de Shopify desde /pages/redirect-test-20260727 hacia la portada, confirmamos que la ruta devolvía un 404 antes para que nada real se viera afectado, la revisamos desde varios ángulos y luego la borramos.

La respuesta específica de Cloudflare está en esa última fila. Pasó las redirecciones tal cual y nunca las cacheó, así que tu lógica de redirecciones sigue enteramente bajo el control de Shopify. Tampoco es suerte: Shopify envía cache-control: private, no-store en la propia 301, así que Cloudflare no la cachearía ni aunque se lo pidieras. Las cadenas de consulta sobreviven, el apex funciona y el HTTP sin cifrar funciona.

Merece la pena conocer un detalle de la limpieza, porque parece un problema de Cloudflare y no lo es. Después de borrar la redirección, la URL desnuda siguió sirviendo la vieja 301 durante unos treinta segundos, mientras una versión de la misma URL con rompe-caché ya devolvía 404. Eso era un solo nodo de edge de Shopify guardando una copia obsoleta, no Cloudflare: cf-cache-status se mantuvo en DYNAMIC todo el rato y la variante con cadena de consulta era correcta de inmediato. Se resolvió solo. Así que, después de cambiar o eliminar una redirección, dale un minuto antes de concluir que no funcionó, y prueba con un rompe-caché si tienes dudas.

Esto también enlaza con el matiz del cacheo de antes, y corta por los dos lados. Con el cacheo del edge desactivado, los cambios de redirecciones surten efecto al instante, lo cual es una ventaja accidental. Si más adelante activas el cacheo de HTML en el edge, las redirecciones también pueden quedar cacheadas ahí y tus ediciones dejarán de aparecer de inmediato. Si tomas ese camino, excluye las rutas de redirección de la regla de caché o incorpora un paso de purga en la herramienta que uses para gestionar redirecciones en masa.

Montarlo antes de que la tienda sea pública

No necesitas un escaparate lanzado para configurar y probar nada de esto. Suele ser más inteligente hacerlo mientras la tienda sigue siendo privada, para que la detección de O2O, el aprovisionamiento de SSL y la prueba de checkout ocurran donde ningún cliente pueda toparse con una configuración a medias. El único requisito es un plan de pago de Shopify, porque los dominios personalizados no están disponibles en una prueba gratuita. Eso sí, no hace falta lanzar la tienda: un plan de pago detrás de su página de contraseña es todo lo que la configuración necesita. Si estás en una tienda de desarrollo de Partner gratuita, que restringe los dominios personalizados, transfiérela primero a un plan de pago y luego sigue los mismos pasos.

Entonces, ¿deberías usarlo?

Conviértelo de un sí o no en una decisión sobre qué necesitas en el edge, porque es lo único que justifica el compromiso.

Steve_TopNewYork y sophia24, usuarios de la Shopify Community, llegaron los dos a esa tercera razón en el mismo hilo, y es el coste que los comerciantes infravaloran. El proxy rara vez es lo que se rompe, pero una vez está en el camino es una capa más que tienes que descartar a las dos de la mañana, cuando el checkout se comporta raro y todavía no sabes por qué. Eso es un impuesto real para un equipo pequeño, y solo vale la pena pagarlo por una función que puedas nombrar.

Si lo usas, trata la lista de comprobación como innegociable: un CNAME proxiado a shops.myshopify.com, confirmar que aparece el icono de Shopify, dejar Always Use HTTPS desactivado, excluir la ruta ACME de tu redirección a HTTPS y revisar la fecha de renovación del certificado igual que revisarías que una copia de seguridad se ejecutó de verdad. Configurado así, muchas tiendas funcionan con Cloudflare delante de Shopify sin dramas. Sáltate esos pasos y habrás montado exactamente la rotura silenciosa que la advertencia intenta evitar.

La versión corta, en vídeo: Field Notes: Cloudflare in front of Shopify repasa qué arregló O2O y las dos cosas que un servicio de edge te muestra y Shopify no.

Preguntas frecuentes

¿Es seguro poner Cloudflare delante de una tienda Shopify?

Es mucho más viable que antes, pero Shopify no lo admite oficialmente, así que es una decisión calculada y no una opción libre de riesgo. El problema de enrutamiento que rompía tiendas, dos zonas de Cloudflare colisionando, lo resolvió la función Orange-to-Orange (O2O) de Cloudflare. Bien configurado, es decir, con un CNAME proxiado a shops.myshopify.com, sin Always Use HTTPS y con la ruta del desafío ACME excluida de cualquier redirección a HTTPS, muchas tiendas funcionan así de forma fiable. La documentación de Shopify sigue diciendo que las configuraciones de proxy de Cloudflare, incluida O2O, no son compatibles y podrían romperse en cualquier momento, porque no pueden garantizar el comportamiento de una capa de proxy que no controlan. El resumen honesto: técnicamente sólido cuando se monta bien, oficialmente no compatible, y mejor reservado para tiendas que necesitan algo en el edge que Shopify no ofrece.

¿Qué es Orange-to-Orange (O2O)?

Orange-to-Orange es la función de enrutamiento de Cloudflare para cuando un cliente de Cloudflare apunta su dominio proxiado a un servicio que también es cliente de Cloudflare. El proxy de Cloudflare se muestra como una nube naranja en el panel, así que dos zonas de Cloudflare apiladas son orange-to-orange. Shopify es cliente de Cloudflare for SaaS, de modo que una tienda Shopify es exactamente este caso. Antes de O2O, Cloudflare no podía determinar de forma fiable qué zona debía quedarse con la petición y las dos colisionaban. O2O detecta que el destino del CNAME pertenece a otro cliente de Cloudflare y enruta la petición primero por tu zona y después por la del proveedor, en orden. Puedes confirmar que funciona cuando aparece un pequeño icono de Shopify junto al registro CNAME en tu panel de Cloudflare.

¿Por qué dice Shopify que Cloudflare no es compatible?

La documentación de Shopify da tres razones principales. Dos se sostienen bien. Primera, SSL: Shopify emite y renueva certificados a través de Let’s Encrypt usando un desafío HTTP de ACME, y cualquier proxy delante es una cosa más que puede interferir con esa validación. Segunda, respuesta a incidentes: cuando la propia infraestructura de Shopify tiene un problema, los proxies extra delante de la tienda le complican a Shopify redirigir el tráfico para esquivarlo, lo que aumenta tu exposición a caídas en lugar de reducirla. La tercera, la detección de bots, es más floja: Shopify argumenta que el tráfico que pasa por Cloudflare llega con atributos de petición alterados, pero Cloudflare opera una de las mayores redes de gestión de bots del mundo, así que la mayoría de tiendas gana más filtrado de bots en el edge del que Shopify pierde en señal. Ninguna de estas razones significa que la configuración no pueda funcionar. Significan que Shopify no va a asumir responsabilidad por el comportamiento de una capa que no le pertenece.

¿Por qué falla el certificado SSL de mi tienda Shopify detrás de Cloudflare?

Casi siempre por el ajuste Always Use HTTPS. Shopify valida la propiedad del dominio y renueva los certificados SSL respondiendo a un desafío servido en la ruta /.well-known/acme-challenge/. Always Use HTTPS fuerza una redirección en cada petición, incluida esa ruta, así que el desafío nunca se completa y el certificado no se puede emitir ni renovar. La tienda sigue funcionando con el certificado existente hasta que caduca, y entonces el dominio queda inseguro o deja de conectar. La solución que documenta Cloudflare es dejar Always Use HTTPS desactivado y, en su lugar, crear una regla de redirección que fuerce HTTPS para todo excepto la ruta /.well-known/acme-challenge/.

¿Tengo que ponerme un recordatorio en el calendario para revisar la renovación del SSL y que no se me rompa la tienda?

No, no si está bien configurado. La renovación está pensada para funcionar sola. El certificado que ven realmente tus visitantes es el propio certificado de edge de Cloudflare, que Cloudflare valida por DNS y renueva automáticamente, así que nunca depende de la ruta del desafío ACME. Detrás, el certificado de origen de Shopify se renueva a través de Let’s Encrypt en segundo plano, y eso sigue funcionando mientras Always Use HTTPS esté desactivado y la ruta /.well-known/acme-challenge/ no se esté redirigiendo. Ejecuta una vez la prueba de curl después del montaje para confirmar que esa ruta devuelve un 404 y no una redirección, y la renovación automática tendrá lo que necesita. Si quieres una red de seguridad, la herramienta adecuada no es un recordatorio manual de calendario sobre el que tengas que actuar, es un monitor automático de caducidad de SSL que te envíe un correo si al certificado le quedan un par de semanas para expirar. Así nada depende de que te acuerdes de un aniversario.

¿Cómo me enteraría antes de que un problema de certificado tumbe la tienda?

Monta monitorización para que te avisen, en lugar de enterarte por un cliente. Un monitor gratuito de SSL y disponibilidad como UptimeRobot, Better Uptime o un servicio similar puede vigilar el dominio y avisarte días antes de que caduque un certificado, o en el momento en que HTTPS empiece a fallar. Cloudflare también puede enviar notificaciones sobre problemas de certificados y de origen desde el área de Notifications del panel. Con cualquiera de las dos cosas, el fallo silencioso de renovación que describe el único riesgo real de esta configuración deja de ser silencioso: recibes un correo con semanas de margen, mucho antes de que el candado se rompa para los compradores.

¿Siguen funcionando las redirecciones de URL de Shopify detrás de un proxy de Cloudflare?

Sí. Lo probamos de principio a fin en una tienda proxiada: una 301 creada en el admin de Shopify entró en vigor de inmediato, sin espera de propagación, devolvió la 301 y la cabecera location correctas, siguió hasta un 200 en el destino en un solo salto, conservó las cadenas de consulta como ?utm_source=test y funcionó desde el dominio apex y por HTTP sin cifrar. Cloudflare pasó la redirección tal cual y nunca la cacheó, reportando cf-cache-status: DYNAMIC en cada petición, así que tu lógica de redirecciones sigue enteramente bajo el control de Shopify. Shopify además envía cache-control: private, no-store en la propia 301, así que Cloudflare no la cachearía ni aunque lo configuraras para ello. Un matiz: después de cambiar o eliminar una redirección, un nodo de edge de Shopify puede servir una copia obsoleta durante unos treinta segundos, así que dale un minuto y prueba con un rompe-caché antes de concluir que no funcionó. Si más adelante activas el cacheo de HTML en el edge de Cloudflare, excluye las rutas de redirección o añade un paso de purga, porque las redirecciones también se pueden cachear ahí.

¿Puedo configurar Cloudflare en una tienda Shopify que todavía no es pública?

Sí, y a menudo es la forma inteligente de hacerlo. No necesitas un escaparate lanzado, solo un plan de pago de Shopify, ya que los dominios personalizados no están disponibles en una prueba gratuita. Mantén la tienda detrás de su página de contraseña en Online Store y luego Preferences, crea en Cloudflare el mismo CNAME proxiado a shops.myshopify.com usando un host que no estés sirviendo en producción, como un subdominio de staging, y conecta ese host en Shopify en Settings y luego Domains. Shopify aprovisiona el SSL y el panel de Cloudflare muestra el icono de Shopify en cuanto Orange-to-Orange se activa, todo mientras el público solo ve la página de contraseña. Ejecuta la prueba de curl del ACME y un checkout de prueba completo con tus apps activas y, cuando todo pase, quita la contraseña y pon tu dominio real como principal. Sales en vivo sobre una configuración que ya has demostrado. Si estás en una tienda de desarrollo de Partner gratuita, que restringe los dominios personalizados, transfiérela primero a un plan de pago.