From c89b7d20ccf4c6d1302b16fcb2a7d919d8743c6a Mon Sep 17 00:00:00 2001 From: patternn Date: Mon, 2 Nov 2026 18:32:51 +0000 Subject: [PATCH] adsense r23: plan de contenido (20 bh + hubs/watch/guias hc) + borrador como-trabajamos + checklist de postulacion --- docs/adsense/checklist-postulacion.md | 40 ++++++++++ docs/adsense/como-trabajamos-borrador.md | 72 ++++++++++++++++++ docs/adsense/plan-contenido.md | 94 ++++++++++++++++++++++++ 3 files changed, 206 insertions(+) create mode 100644 docs/adsense/checklist-postulacion.md create mode 100644 docs/adsense/como-trabajamos-borrador.md create mode 100644 docs/adsense/plan-contenido.md diff --git a/docs/adsense/checklist-postulacion.md b/docs/adsense/checklist-postulacion.md new file mode 100644 index 0000000..eb6a8f3 --- /dev/null +++ b/docs/adsense/checklist-postulacion.md @@ -0,0 +1,40 @@ +# Checklist de postulación a AdSense (r23) — medible por sitio + +Estado inicial: bitcoinhotels 4/10 en verde · hardcap 3/10 en verde (ver +auditoría r23 en el informe de la ronda). + +## Común (ambos sitios) +1. [ ] **Sitemap dinámico completo**: cada URL indexable está en el sitemap y + responde 200 (métrica: |sitemap| == |páginas indexables|; hoy bh 4/~22, + hc 3/~790). +2. [ ] **Sin páginas finas indexadas**: toda URL indexable con ≥300 palabras + propias o marcada noindex (hoy: bh 12 hoteles entre 7-105 palabras — + enriquecer o noindex; hc ~762 notas de agregación — decisión: noindex a + notas <150 palabras propias hasta tener síntesis editorial). +3. [ ] **Páginas de confianza completas**: About, Contact, Privacy (con + mención explícita de Google AdSense, cookies y analytics), Terms — 200 y + sustanciales (hoy bh: falta Contact, Privacy sin mencionar Google/AdSense; + hc: faltan Contact/Privacy/Terms). +4. [ ] **"Cómo trabajamos" publicada** (borrador r23 aprobado). +5. [ ] **CWV móvil ≥90 en Lighthouse (mediana de 3)** en home + 3 interiores + (hoy bh 0.94 ✓ en home; hc 0.59 ✗). +6. [ ] **ads.txt y meta google-adsense-account correctos** (hoy: ambos sitios + ✓ — se mantiene). +7. [ ] **robots.txt sin bloqueos indebidos** (hoy ✓ ambos). +8. [ ] **Enlaces rotos = 0** en navegación principal y footer (pasada mensual + automatizable en CI). +9. [ ] **GSC + Bing dados de alta** (verificación DNS Cloudflare) con ≥80% de + URLs del sitemap rastreadas en 28 días (dato GSC del operador). +10. [ ] **4 semanas de publicación constante** al ritmo aprobado del plan + (bh 2/semana; hc ~2,5/semana) sin huecos >7 días, con sitemap actualizado + en cada publicación. + +## Por sitio (adicional) +- bitcoinhotels: 12 hoteles enriquecidos a ≥300 palabras + ≥8 de las 20 guías + nuevas publicadas antes de postular. +- hardcap: 12 hubs publicados + 4 Security Watch + ≥5 guías de custodia antes + de postular. + +## Regla de re-postulación tras rechazo +No antes de 30 días ni sin cerrar TODOS los ítems en rojo/amarillo de la +auditoría + dos semanas más de publicación constante. diff --git a/docs/adsense/como-trabajamos-borrador.md b/docs/adsense/como-trabajamos-borrador.md new file mode 100644 index 0000000..6325bf2 --- /dev/null +++ b/docs/adsense/como-trabajamos-borrador.md @@ -0,0 +1,72 @@ +# "Cómo trabajamos" — borrador para revisión del operador (r23) + +> Borrador único con dos variantes de encabezado (una por sitio). Sin publicar +> hasta tu OK. Tono: el de la voz v3 (seco, verificable, sin marketing). + +--- + +## Variante bitcoinhotels.org + +### Cómo trabajamos + +Bitcoin Hotels es operado por **Cayce**, una entidad autónoma de software — un +agente de IA — con supervisión humana de patternn (Próspera ZEDE). + +**Cómo elegimos qué listamos.** Un alojamiento aparece aquí solo si acepta +bitcoin como forma de pago, verificado contra BTC Map (datos abiertos, licencia +ODbL, con atribución) y contra nuestro propio registro de verificación manual. +Cuando una verificación caduca, el listado se marca o se retira. + +**Cómo escribimos las guías.** Cada guía la redacta Cayce a partir de fuentes +primarias: datos de venues, listados propios y documentación verificable. Toda +afirmación con cifras lleva su fuente y su fecha. Si una guía no puede +sostenerse con fuentes, no se publica. + +**Cómo corregimos errores.** Los errores se corrigen en la propia página, con +fecha. Si un dato cambió (un hotel deja de aceptar bitcoin, un ATM sube su +comisión), la guía se actualiza y la fecha de verificación cambia con ella. Las +correcciones importantes quedan anotadas al pie. + +**Publicidad.** El sitio se sostiene con publicidad (AdSense de Google) y con +donaciones en sats. La publicidad no influye en qué listamos ni en qué +escribimos: no hay plazas pagadas ni colocación de producto. + +**Contacto.** [correo de contacto — PENDIENTE: decidir y crear] · Nostr: [npub +de la entidad — PENDIENTE: publicar o no]. + +--- + +## Variante hardcap.news + +### Cómo trabajamos + +Hardcap es operado por **Cayce**, una entidad autónoma de software — un agente +de IA — con supervisión humana de patternn. + +**Qué publicamos y qué no.** Señal, no ruido: qué pasó, por qué importa y de +dónde sale el dato. Cada nota lleva URL y fecha de fuente. Si no podemos +sustentar una afirmación, no la publicamos. + +**Cómo elegimos fuentes.** Fuentes primarias primero: comunicados, datos +on-chain, documentos judiciales, especificaciones técnicas. La agregación de +terceros se cita como tal y se verifica contra la primaria cuando existe. + +**Cómo escribimos las guías.** Con el mismo estándar que las notas: pasos +reproducibles, fuentes con fecha, advertencias donde un error cuesta dinero. + +**Cómo corregimos errores.** En la misma página, con fecha visible. Las +correcciones de sustancia quedan anotadas; en Nostr, la corrección se publica +también como nota nueva referida a la original. + +**Publicidad.** Publicidad (AdSense de Google) y donaciones en sats. Ningún +anunciante compra cobertura ni mención: las marcas de hardware se tratan solo +como noticia o referencia técnica, nunca como recomendación pagada. + +**Contacto.** [PENDIENTE: mismo correo/npub que bitcoinhotels o distinto] + +--- + +## Pendientes del operador sobre este borrador +1. Correo de contacto real (y decisión de publicar o no el npub). +2. Duración del historial de correcciones (¿mostrar siempre o últimos 90 días?). +3. Añadir o no sección de equipo/supervisión humana con nombre del operador. diff --git a/docs/adsense/plan-contenido.md b/docs/adsense/plan-contenido.md new file mode 100644 index 0000000..20c9019 --- /dev/null +++ b/docs/adsense/plan-contenido.md @@ -0,0 +1,94 @@ +# Programa AdSense — Plan de contenido (r23, para aprobación del operador) + +Regla general: NADA se publica sin tu OK explícito a este plan. Sin producción de +contenido largo hasta entonces. + +## A. bitcoinhotels.org — 20 piezas candidatas + +Fuentes: BTC Map API v4 (datos de venues, licencia ODbL — atribución obligatoria +en cada guía: "Venue data © BTC Map contributors (ODbL)"), listings propios +(hotels.json + verificación manual), eventos del propio pipeline de cayce +(btcmap events), guías existentes como base. + +### Guías de ciudad (12) +1. El Zonte de bolsillo: pagar con Lightning en 48 h (ámbito: la playa que no + usa efectivo; fuentes: BTC Map venues El Zonte + listings propios; ~900 pal.) +2. San Salvador: mapa de gastos reales en sats (transporte, comida, hospedaje; + BTC Map + precios verificados; ~900) +3. Lugano: la ciudad-plan de Bitcoin (Plan B, merchants, límites prácticos; + BTC Map + city sources; ~800) +4. Zúrich sin tarjeta: hoteles y vida diaria en BTC (nuestro listing Dolder + + BTC Map Zürich; ~800) +5. Ámsterdam para un pagador en sats (ATMs, cafés, el evento anual; + BTC Map + nuestros eventos; ~800) +6. Praga: la escena que no se fue (venues históricas + actuales; BTC Map; + ~800) +7. Lisboa: trabajar y pagar una semana en bitcoin (coworking, cafés, ATMs; + ~800) +8. Ciudad de México / CDMX: ruta de tres días sin banco (BTC Map + colonias; + ~850) +9. Buenos Aires con Lightning: la cotidianidad integrada (transporte, recargas, + comidas; ~850) +10. Roatán y Próspera: jurisdicción nativa (tender legal, hospedajes; listings + propios + fuentes jurisdiccionales; ~800) +11. Ljubljana: la escena silenciosa de Europa del Este (~750) +12. Bangkok/Chiang Mai: el sudeste que acepta sats (remotos y nómadas; ~750) + +### Guías de eventos (4) +13. Calendario 2026-27 de eventos bitcoin: cuáles valen el vuelo (datos propios + de events + btcmap; ~700, actualizable) +14. Sobrevivir (y pagar) una conferencia bitcoin: presupuesto en sats por día + (~700) +15. Dónde dormir durante los grandes eventos (hoteles que aceptan btc cerca de + sedes — cruce propio de events×hotels; ~650) +16. Cómo conocer gente antes de llegar: meetups y Nostr como agenda (~650) + +### Guías prácticas (4) +17. Comprar btc sin banco por ciudad: operadores y topes KYC (actualización de + la guía ATM con tabla por ciudad; ~900) +18. Tarjetas regalo: el rescate cuando el comercio no acepta btc (~700) +19. eSIM y datos pagados en sats, país por país (~650) +20. Propinas en sats: la etiqueta y las herramientas (~600) + +## B. hardcap.news — arquitectura de páginas + +1. Hubs de tema (burbuja + editorial + notas): los 12 editorials existentes + (security, privacy, custody, regulation, mining, ETF, lightning, wallets, + exchanges, travel-opsec, energy, adoption) pasan a página-hub permanente con + la síntesis arriba, el histórico de notas abajo y enlaces a guías. ~600 pal. + propias por hub + histórico. +2. Security Watch (semanal): síntesis de la semana en seguridad (qué pasó, qué + patrón sigue, qué hacer) con enlaces a las notas fuente de la propia semana; + 400-600 palabras, viernes. +3. 10 guías permanentes de custodia DIY (títulos): + 1) Semilla en acero con herramientas de mano; 2) Passphrase: el segundo + factor que viaja en tu cabeza; 3) Multisig 2-de-3 paso a paso (sin marcas: + "firmware verificable"); 4) Herencia sin notario: timelock + cartas de + recuperación; 5) Verificar una transacción en pantalla: el hábito que + evita el malware; 6) Firma en frío con dos dispositivos viejos; + 7) Reparto geográfico de respaldos sin confianza en terceros; 8) Cartera + señuelo: cuándo ayuda y cuándo es teatro; 9) Verificar firmware antes de + primera uso (hash y attestation, sin marcas); 10) El simulacro: restaurar + desde cero en 10 minutos, cada trimestre. + Fuentes: documentación de protocolos (BIP-39/32/174), Bitcoin OWASP, + guías de fabricantes SOLO como referencia técnica (sin nombres en bh; + en hardcap las marcas están permitidas por R1-news pero se evita endoso), + datasets propios (wrench-attack dataset). 800-1200 palabras c/u. + +## C. Ritmo propuesto (sustanciales/semana) +- bitcoinhotels: 2 guías/semana (martes y viernes). +- hardcap: 1 hub/semana + Security Watch semanal + 1 guía de custodia cada + 2 semanas → ~2,5/semana. +- Primeras 4 semanas: además, enriquecer los 12 hoteles a ≥300 palabras propias + cada uno (2 por semana) para eliminar las páginas finas. + +## D. Criterio de calidad de pieza larga (gate interno) +1. ≥600 palabras de texto propio (guías: 600-1200). +2. ≥3 fuentes primarias citadas con URL y fecha (formato señal de hardcap). +3. Todo dato numérico reproducible: la fuente permite verificarlo. +4. Sin relleno: si un párrafo no aporta dato o criterio, se borra (R8 del + guard como filosofía). +5. El guard revisa cada pieza antes de publicar (R1-R9); en bitcoinhotels, + además, cero marcas de hardware (blocklist). +6. Atribución de licencias cuando hay datos abiertos (BTC Map → ODbL). +7. Frescura: cada guía lleva fecha de verificación y se revisa cada 90 días.