Dilluns em va escriure un propietari d'un pis turístic. Tenia un problema amb el programa de la seva gestora i em demanava ajuda. Dimecres, per telèfon, li vaig preguntar com m'havia trobat. «Per ChatGPT.» Li havia explicat el problema i el meu nom li havia sortit el primer, amb el telèfon inclòs.
\nQui busca algú per resoldre un problema ja no només obre Google. Cada vegada més gent li pregunta a un assistent com ChatGPT, i l'assistent no torna deu enllaços: en recomana un o dos. Vaig voler veure-ho amb dades: si la visita havia quedat apuntada a la web, quins robots d'OpenAI llegeixen les meves webs de debò i quins només en porten el nom.
\nQuan ChatGPT enllaça una web en una resposta, hi afegeix ?utm_source=chatgpt.com. La pàgina no en fa res, però queda escrit al registre d'accés, el fitxer on el servidor apunta cada petició que rep. Al de joansanfeliu.com hi és:
2026-09-14 09:36:17 UTC GET /es/?utm_source=chatgpt.com 200
Eren les 11:36 a Barcelona. El correu va arribar a les 12:11.
\nLes meves webs són a AWS Amplify, que guarda cada petició en el format de CloudFront i la dona amb una ordre (les dates, en la sintaxi del date de macOS):
aws amplify generate-access-logs \\
--region eu-west-1 \\
--app-id <id-de-l-app> \\
--domain-name joansanfeliu.com \\
--start-time $(date -u -v-7d +%s) \\
--end-time $(date -u +%s) \\
--query logUrl --output text
Retorna una adreça temporal a un CSV amb una fila per petició. Dues coses em van fer perdre temps:
\nUnable to complete request for the given time range, reduce time range and try again i només va acceptar set dies.cs\\(User-Agent) i cs\\(Referer), i dins les cel·les també hi ha barres invertides (utm_source\\=chatgpt.com). El primer recompte, buscant la columna cs(User-Agent), em va donar zero robots.Llegint-ho bé:
\nimport csv
from urllib.parse import unquote
def neteja(text):
return unquote(unquote(text)).replace('\\\\', '')
files = csv.reader(open('joansanfeliu.csv', newline=''))
I = {neteja(nom): i for i, nom in enumerate(next(files))}
for f in files:
if 'utm_source=chatgpt.com' in neteja(f[I['cs-uri-query']]):
print(f[I['date']], f[I['time']], f[I['cs-uri-stem']])
OpenAI té tres agents, i la seva documentació diu per a què serveix cadascun:
\nrobots.txt poden no aplicar-s'hi.En catorze dies, als registres de dues de les webs:
\n/robots.txt./robots.txt.El que més demana GPTBot és el mapa del lloc (sitemap-index.xml a l'una, sitemap.xml a l'altra). Totes aquestes peticions surten d'adreces que OpenAI publica com a seves.
A joansanfeliu.com, en set dies, surt una altra cosa:
\nMés de la meitat de la resta no demana pàgines: demana /.env, /.aws/credentials, /@fs/etc/passwd o /id_ed25519, els fitxers on un projecte mal desplegat deixa contrasenyes i claus. /@fs/ és la ruta del servidor de desenvolupament de Vite per servir fitxers del disc, i joansanfeliu.com està fet amb Vite. Escriure el nom d'un robot d'OpenAI a l'agent d'usuari, la capçalera amb què cada programa diu qui és, no costa res.
Comptant tots els agents, aquella setmana hi va haver 2.059 peticions buscant fitxers d'aquest tipus. Totes van rebre HTML o un error: 1.765 van rebre un 200 amb la portada, perquè la web té una regla que envia qualsevol ruta desconeguda cap a l'index.html (és una web d'una sola pàgina, que dibuixa el contingut amb JavaScript), i 216 un 404. A agencia. i formacio., en catorze dies, no n'hi va haver cap.
L'agent no prova res. L'adreça d'origen, en canvi, no es pot inventar en una connexió HTTP, i OpenAI publica les seves en tres fitxers: openai.com/gptbot.json, openai.com/searchbot.json i openai.com/chatgpt-user.json.
import ipaddress
import json
import urllib.request
xarxes = []
for nom in ['gptbot', 'searchbot', 'chatgpt-user']:
with urllib.request.urlopen(f'https://openai.com/{nom}.json') as r:
prefixos = json.load(r)['prefixes']
xarxes += [ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix')) for p in prefixos]
def es_openai(ip):
adreca = ipaddress.ip_address(ip)
return any(adreca in xarxa for xarxa in xarxes)
Una fila és d'OpenAI si l'agent ho diu i es_openai() ho confirma amb la columna c-ip. Els fitxers es refresquen: el de ChatGPT-User que vaig baixar era de l'11 de setembre, i una adreça que OpenAI ja no fa servir pot no ser-hi. Per això els números d'abans diuen «des d'adreces d'OpenAI» i no «falsos».
No sé què va fer que ChatGPT em recomanés. Sé què hi ha a cada web:
\nrobots.txt que dona permís pel seu nom a GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot i la resta de robots d'IA coneguts, amb un comentari que explica per què, i un /llms.txt: un resum en text pla, pensat per a models, de qui som, on treballem i com.robots.txt que ho permet tot sense anomenar ningú, i cap llms.txt.index.html les dades estructurades de la persona i de l'organització (JSON-LD, un format que els cercadors llegeixen sense haver d'interpretar el text).La visita de ChatGPT va entrar per joansanfeliu.com, una web sense llms.txt.
Actualització del 16 de setembre al vespre. El mateix dia de publicar això ho vaig canviar:
\nrobots.txt que anomena els robots d'IA, amb Content-Signal: search=yes, ai-input=yes, ai-train=yes, i el seu /llms.txt./.env respon un 404.utm_source=chatgpt.com: són les visites que us arriben des de ChatGPT.El segon pas us diu si ja us recomanen. El tercer, qui entra a la web dient que és un altre.
", "url": "https://formacio.joansanfeliu.com/blog/trobat-per-chatgpt-registres-web", "title": "M'han trobat per ChatGPT: què diuen els registres de la web", "summary": "Un propietari d'un pis turístic em va trobar preguntant a ChatGPT. Als registres d'accés es veu la visita, quins robots d'OpenAI llegeixen la web de debò i quins se'n fan passar per buscar contrasenyes.", "date_modified": "2026-09-16T00:00:00.000Z", "author": { "name": "Joan Sanfeliu", "url": "https://joansanfeliu.com" }, "tags": [ "chatgpt", "aeo", "amplify", "logs", "seguretat" ] }, { "id": "https://formacio.joansanfeliu.com/blog/donar-alta-client-escrivint-nomes-url", "content_html": "Quan algú vol provar un producte de programari, cada camp extra al formulari de registre és una oportunitat perquè marxi. Si per donar-se d'alta li demanes nom del negoci, logotip, colors i dades de cada propietat, la majoria tancarà la pestanya abans d'acabar. Aquesta setmana he tancat un flux de registre que demana tres coses: correu, contrasenya i l'adreça web del negoci. El sistema entra a aquella pàgina, en treu la identitat visual, crea el compte i, pocs minuts després, la pàgina pública del client ja és en línia sense que ningú més hi hagi tocat res.
\nLa decisió de producte és simple: si la informació ja existeix en algun lloc, no la demanis. La web d'un negoci ja porta el nom, el logo i els colors. Només cal anar-los a buscar.
\nL'experiència d'un usuari nou té tres passos:
\nCap d'aquests passos requereix un humà a l'altre costat. La web neix sola. Això és el que internament en dic auto-debut: la primera publicació de la web es dispara quan la primera recollida de valoracions acaba, sense que l'usuari hagi de prémer cap botó.
\nPOST /public/signup: alta atòmica amb rollbackTot comença amb un sol endpoint públic:
\nPOST /public/signup
Body: { email, password, websiteUrl }
L'endpoint fa dues coses en seqüència: crea el tenant (el compte del negoci dins el sistema, amb la seva identitat visual extreta de la URL) i crea l'usuari a Cognito, el servei d'autenticació d'AWS que gestiona correus i contrasenyes. Si la segona operació falla —per exemple perquè el correu ja existeix a Cognito—, el sistema esborra el tenant que acaba de crear. Sense aquest rollback quedaries amb comptes orfes: tenants sense cap usuari que hi pugui entrar.
\nL'extracció de marca passa dins la creació del tenant. El sistema fa un GET a la websiteUrl que l'usuari ha proporcionat, analitza l'HTML i en treu:
<title> o de les metadades Open Graph).No és perfecte. Hi ha webs que porten tot el contingut carregat amb JavaScript i el GET simple no veu res. Hi ha logos que són SVG incrustats que costen de parsejar. Però en la majoria de casos n'hi ha prou per tenir un punt de partida raonable que el client pot corregir després.
\nUn cop el tenant té la identitat visual bàsica, el sistema la passa a Amazon Bedrock (el servei d'AWS que dóna accés a models de llenguatge) per prendre decisions de disseny: quina tipografia complementa aquells colors, quina disposició d'elements funciona millor, quin to de text encaixa amb la marca.
\nTot passa dins d'un sol endpoint intern que executa la cadena sencera:
\nEl resultat és una URL pública funcional. El client no ha pujat cap foto, no ha triat cap plantilla, no ha escrit cap text.
\nLa pàgina pública no és estàtica. Cada vegada que acaba una recollida de valoracions, la web es torna a generar per incorporar les noves dades.
\nEl mecanisme és un comptador pendingJobs al registre del tenant. Cada tasca en curs l'incrementa. Quan una tasca acaba, el decrementa. Quan arriba a zero, el sistema crida publishTenantSite, que torna a executar tota la cadena de generació i desplegament.
Això vol dir que la primera recollida —la gratuïta que forma part de l'onboarding— és la que dispara la primera publicació de la web. L'auto-debut no és un pas separat: és una conseqüència natural de que pendingJobs arribi a zero per primera vegada.
El pla gratuït és deliberadament curt: una propietat, un canal de recollida i una recollida amb un sostre d'unes trenta valoracions. Aquests límits s'apliquen al servidor, no a la interfície. No és un avís que diu \"has arribat al límit\": és un rebuig net de l'operació.
\nLa raó és pràctica. Si el límit és només visual, qualsevol crida directa a l'API se'l salta. Si és al servidor, no hi ha escletxa. El codi comprova el pla del tenant abans d'executar qualsevol operació que consumeixi quota.
\nEl pla gratuït té prou corda perquè l'usuari vegi el producte funcionar de veritat —rep valoracions, la web es publica— però no prou perquè s'hi quedi indefinidament sense pagar.
\nHe provat el funnel sencer amb un test E2E que reprodueix tot el camí:
\nEl test confirma que no hi ha cap pas manual entremig. Des del POST /public/signup fins a la web desplegada a Amplify, tot passa sense intervenció. Si algun dia algú trenca la cadena —un canvi a Bedrock, un límit nou a Amplify, un error al rollback—, el test ho detectarà abans que cap usuari real s'hi trobi.
Mailchimp és una bona eina. Però té un preu: a partir d'uns quants centenars de contactes, pagues cada mes tant si envies com si no. I cedeixes les dades dels teus subscriptors a un tercer.
\nPer a una llista petita, on l'únic que necessites és guardar adreces, enviar un correu i permetre la baixa, la plataforma és excés. Pots construir el que necessites amb el que ja tens a AWS.
\nAixò és el que he fet a joan-utils, el meu stack de CloudFormation a eu-west-3.
Una taula DynamoDB en mode PAY_PER_REQUEST. La clau de partició és email. Cada ítem té un camp token (UUID v4), un camp status i un createdAt.
Els estats possibles són tres: pending, active i unsubscribed. La transició és sempre cap endavant: mai es torna a pending des d'active.
Hi ha un índex secundari global (token-index) sobre el camp token. Sense aquest índex, confirmar o donar de baixa una adreça requeriria un scan de tota la taula. Amb l'índex, és una consulta puntual.
Una sola Lambda en Node 24, arquitectura arm64, memòria 512 MB, darrere d'un HTTP API de API Gateway. Tres rutes:
POST /newsletter/subscribeGET /newsletter/confirmGET /newsletter/unsubscribeSi acceptes una adreça sense confirmar, qualsevol pot subscriure qualsevol altra persona. Rebràs rebots. SES et penalitza pels rebots: si superes un cert percentatge, et suspenen l'enviament.
\nAmb la doble confirmació, l'adreça no entra a la llista fins que el propietari fa clic. Punt.
\nEl flux és: reps el POST, guardes l'ítem en estat pending, envies el correu de confirmació amb l'enllaç GET /newsletter/confirm?token=UUID. Quan l'usuari fa clic, passes l'ítem a active.
Cada correu d'enviament ha de portar un enllaç de baixa. No a la pàgina principal, no a un formulari: un enllaç directe que faci la baixa en un sol clic.
\nEl token que guardes a DynamoDB serveix per a les dues coses: confirmació i baixa. No cal generar-ne un de nou per a cada enviament.
\nEl que no pots fer és respondre 404 si l'adreça ja és unsubscribed. Respondries informació sobre l'estat de la llista. Retorna sempre 200.
Si algú envia el formulari dues vegades amb la mateixa adreça i l'estat ja és active, no reenvies el correu de confirmació. Retorna 200 i prou. Si reenviessis, estaríes confirmant implícitament que aquella adreça és a la llista. No filtris informació.
Aquestes són les mesures que he obtingut:
\nEl cold start de 518 ms és acceptable per a un formulari web. No és un camí crític.
\nEl cost del tram:
\nPer a una llista de menys de deu mil subscriptors, el cost mensual és essencialment zero si no envies cada dia.
\nAquesta solució cobreix: guardar adreces, confirmar, donar de baixa, enviar un correu simple.
\nNo cobreix:
\nSi necessites alguna d'aquestes coses, una plataforma dedicada et sortirà més barata en hores de feina. La decisió no és ideològica: és quant val el teu temps.
\nDos problemes que no eren evidents:
\nPrimer, l'índex secundari global triga uns segons a estar disponible després de crear la taula. En un desplegament de CloudFormation en un entorn nou, la primera invocació pot fallar si la Lambda s'executa just després de la creació. Ho vaig resoldre afegint un DependsOn explícit al recurs de la Lambda cap a la taula, i acceptant que el primer cold start pot trobar l'índex encara en estat CREATING. En producció no és un problema perquè la taula ja existeix.
Segon, SES a eu-west-3 requereix que el domini estigui verificat. Si estàs en sandbox, a més, les adreces de destinació també han d'estar verificades. Vaig perdre una estona fins que vaig entendre que el problema no era el codi sinó que SES encara no havia sortit del sandbox.
Fa temps que tinc aquí els apunts dels cursos que faig: HTML, CSS, JavaScript i, des\nd'aquesta setmana, AWS serverless. Són material de classe, ordenat i pensat per\nseguir-lo de principi a fi.
\nAquest blog és una altra cosa.
\nEls apunts expliquen com funciona una cosa. Estan pensats perquè algú que comença\nels pugui seguir, i per això són ordenats i previsibles.
\nEl blog explica què m'he trobat construint. Tinc software propi en producció —un\nSaaS de reserves per a restaurants, un parell de productes més i un grapat de coses\npetites que em fan la feina— i cada mes hi ha alguna cosa que no surt com esperava.\nUna factura que no quadra, una decisió d'arquitectura que va sortir malament, un\nservei d'AWS que fa una cosa diferent de la que diu la documentació.
\nAixò és el que hi posaré.
\nNúmeros reals. Si escric sobre costos, seran els meus, tal com surten a la factura.\nNo estimacions ni exemples inventats. Si dic que una cosa em costa 8,40 $, és perquè\nme n'ha costat 8,40.
\nTambé el que no ha funcionat. Els posts on tot surt bé a la primera no serveixen a\nningú, perquè no és així com va. Si vaig trigar tres dies a trobar per què petava,\naixò és el post.
\nRes copiat. Hi ha blogs de serverless molt millors que aquest, i els llegeixo. Quan\nparteixi d'una idea d'algú altre, ho diré i hi posaré l'enllaç.
\nUn post a la setmana, els dilluns. Si alguna setmana no tinc res que valgui la pena,\nno publicaré per publicar.
\nSi vols que t'avisi quan n'hi hagi un de nou, tens el formulari aquí sota. Un correu\nper setmana com a molt, i te'n pots donar de baixa quan vulguis.
", "url": "https://formacio.joansanfeliu.com/blog/que-hi-trobaras", "title": "Què hi trobaràs aquí", "summary": "Per què obro un blog al costat dels apunts, què hi publicaré i cada quan.", "date_modified": "2026-08-30T00:00:00.000Z", "author": { "name": "Joan Sanfeliu", "url": "https://joansanfeliu.com" }, "tags": [ "meta" ] } ] }