<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Netsis</title>
	<atom:link href="https://netsis.es/feed" rel="self" type="application/rss+xml" />
	<link>https://netsis.es</link>
	<description></description>
	<lastBuildDate>Sun, 27 Sep 2026 19:23:13 +0000</lastBuildDate>
	<language>es</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>
	<item>
		<title>WordPress hackeado: qué hacer en las primeras horas</title>
		<link>https://netsis.es/blog/wordpress-hackeado-que-hacer.html</link>
					<comments>https://netsis.es/blog/wordpress-hackeado-que-hacer.html#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Sun, 27 Sep 2026 19:23:13 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://netsis.es/blog/wordpress-hackeado-que-hacer.html</guid>

					<description><![CDATA[Qué hacer primero, qué no tocar y cómo cerrar la puerta para que no vuelvan a entrar.]]></description>
										<content:encoded><![CDATA[<p>Abres tu web y te manda a una página de apuestas. O te escribe un cliente porque Chrome le avisa de que el sitio es peligroso, o el hosting te suspende la cuenta por enviar spam. Si te está pasando ahora mismo, no borres nada a ciegas ni restaures la última copia. Primero hay que frenar el daño, después guardar una copia de cómo está todo y solo entonces limpiar, buscando por dónde entraron. Si esa puerta queda abierta, vuelven en días.<br />
Así lo hacemos nosotros cuando nos llaman con un WordPress hackeado. Te sirve para hacerlo tú o para saber qué pedirle a quien lo haga.</p>
<p>Cómo saber si es un hackeo y no un fallo<br />
Un error 500 o una pantalla en blanco casi nunca son un ataque. Lo normal es que sea un plugin que falló al actualizarse o un cambio de versión de PHP, y eso tiene otra solución, la de una web caída o con error 500. Estas señales, en cambio, sí apuntan a que alguien entró:</p>
<p>La web redirige a otra página, a veces solo desde el móvil o solo cuando llegas desde Google. Está hecho así a propósito, para que el dueño, que entra escribiendo la dirección, no lo vea.<br />
Chrome muestra la pantalla roja de sitio peligroso, o en Search Console aparece un aviso en el informe de problemas de seguridad.<br />
Hay usuarios administradores que nadie creó, o tu contraseña de siempre ya no funciona.<br />
Buscas site:tudominio.com en Google y salen páginas que no escribiste, muchas veces en japonés o vendiendo medicamentos.<br />
El hosting te avisa de que tu cuenta envía correo masivo, o tus correos normales empiezan a caer en la carpeta de spam de tus clientes.<br />
Aparecen ficheros PHP dentro de wp-content/uploads, la carpeta de las imágenes, donde no debería haber ninguno.</p>
<p>Lo que no conviene hacer<br />
Con los nervios, lo primero que sale es borrar todo lo que parece raro. Es mala idea por dos motivos. Esos ficheros son la única pista para saber por dónde entraron, y muchas veces el código malicioso va metido dentro de un fichero legítimo del tema o de un plugin, así que al borrarlo la web deja de funcionar.<br />
Restaurar la última copia tampoco suele arreglarlo. Si la infección entró hace tres semanas, la copia de anoche también la lleva. Y aunque fuese anterior, la puerta por la que entraron sigue abierta.<br />
Cambiar solo la contraseña de wp-admin se queda corto, porque quien entra suele dejar puertas traseras que no necesitan ninguna contraseña. Un plugin de seguridad ayuda a detectar lo conocido. Pero las puertas traseras bien hechas van sin disfrazar, dentro de ficheros que parecen normales, y ahí los escáneres automáticos fallan a menudo.</p>
<p>Qué hacer, en este orden</p>
<p>1. Frena lo que está haciendo daño<br />
Si la web redirige a estafas o tu cuenta está enviando spam, eso se corta antes que nada. El spam hunde la reputación de tu dominio, y cuando pasa, tus correos de trabajo acaban en el correo no deseado de tus clientes. Cerrar la web entera solo hace falta si están robando datos, como en una tienda con el pago comprometido.</p>
<p>2. Guarda una copia de todo tal como está<br />
Ficheros y base de datos, guardados fuera del servidor. No es para restaurarla. Es la evidencia que permite averiguar qué tocaron y cuándo, y la que vas a necesitar si luego tienes que explicar a un cliente o a la Agencia de Protección de Datos qué pasó.</p>
<p>3. Busca todo lo que cambió<br />
WordPress permite comparar sus ficheros con los originales, y los plugins del repositorio oficial también. Con WP-CLI son dos órdenes, wp core verify-checksums y wp plugin verify-checksums &#8211;all. A eso hay que sumarle lo que ninguna comparación ve: ficheros PHP en uploads, administradores que nadie creó, tareas programadas raras y código metido en la base de datos, sobre todo en las opciones y en las entradas. Apunta cada fichero con su fecha de modificación, porque esa lista es la que te lleva al paso siguiente.</p>
<p>4. Averigua por dónde entraron<br />
El fichero modificado más antiguo da la fecha, y los registros de acceso del servidor de ese día suelen enseñar la petición que lo creó. Lo más habitual es un plugin o un tema sin actualizar con un fallo conocido. Le siguen las contraseñas robadas, muchas veces por un programa espía en el ordenador de quien administra la web. Si el origen no aparece, lo honesto es decirlo y no inventarse un culpable que quede bien en el informe.</p>
<p>5. Limpia reinstalando, no borrando a mano<br />
El núcleo de WordPress y los plugins se vuelven a instalar desde el original, sin tocar tu contenido. Los ficheros legítimos con código inyectado se restauran, y los que no pintan nada ahí, como las puertas traseras, se eliminan. En la base de datos se limpian solo las filas infectadas. Los administradores y las tareas que creó el atacante, fuera.</p>
<p>6. Cambia todas las claves y echa al atacante<br />
No vale con la de tu usuario. Hay que cambiar las de todos los administradores, la de la base de datos, las del FTP y del panel del hosting, y regenerar las claves secretas de wp-config.php. Esto último cierra todas las sesiones abiertas, incluida la del atacante, que puede seguir dentro aunque cambies la contraseña. Hazlo desde un ordenador que sepas limpio. Si el robo vino de un programa espía, la contraseña nueva se va igual en cuanto la escribas.</p>
<p>7. Pide a Google que revise la web<br />
Si Google la había marcado, el aviso no desaparece solo porque la limpies. Hay que entrar en Search Console, en el informe de problemas de seguridad, confirmar que está resuelto y solicitar la revisión.</p>
<p>8. Vigila los días siguientes<br />
Una reinfección a las 24 o 48 horas quiere decir que quedó una puerta abierta. Por eso nosotros repetimos el análisis completo un par de días después, aunque todo parezca en orden.</p>
<p>Por qué vuelve la infección<br />
Cuando una web se limpia y a la semana está igual, casi siempre es por una de estas cuatro razones:</p>
<p>No se encontró la puerta de entrada y la reinfección, que está automatizada, volvió a pasar por ella.<br />
Quedó una puerta trasera en la base de datos, donde ningún escáner de ficheros mira.<br />
Hay otras webs en la misma cuenta del hosting que siguen infectadas y contagian a la vecina.<br />
La contraseña se está robando en el ordenador de quien administra la web.</p>
<p>La tercera es muy común en cuentas con webs antiguas que ya nadie recuerda, como una tienda que se cerró o una web de pruebas sin actualizar desde hace años. Se limpian todas o no se limpia ninguna.</p>
<p>Cuánto cuesta limpiar un WordPress hackeado<br />
Depende sobre todo de cuántas webs haya en la cuenta y de lo extendida que esté la infección. Con nosotros, la limpieza de un WordPress empieza en 190 € + IVA. Si la necesitas empezada el mismo día laborable, desde 290 €, y si la web está alojada en Netsis, desde 150 €. Te damos el presupuesto cerrado cuando hemos visto lo que hay, antes de empezar.<br />
Incluye buscar la entrada y cerrarla, que es lo que evita pagar dos veces, y un informe con lo que encontramos, por dónde entraron y qué claves quedan por cambiar fuera de la web. No hace falta mover la web a nuestro hosting. La limpiamos donde esté.</p>
<p>Cómo evitar que vuelva a pasar<br />
Lo más habitual es que entren por algo que ya tenía arreglo publicado. Tener pocos plugins, quitar los que no se usan, actualizar cada semana y guardar copias fuera del servidor cubre gran parte del riesgo. Si no tienes tiempo para eso, es justo lo que hace nuestro mantenimiento de WordPress, y si quieres saber cómo está tu web antes de que pase nada, la auditoría de seguridad te lo dice.<br />
Y si lo estás viviendo ahora, llámanos al 986 06 02 70 o escríbenos desde el formulario de abajo con la dirección de la web y lo que ves. Todo el detalle del servicio está en limpieza de malware en WordPress.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://netsis.es/blog/wordpress-hackeado-que-hacer.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Dominio .gal: qué es, quién puede registrarlo y qué exige</title>
		<link>https://netsis.es/blog/dominio-gal-que-es-y-requisitos.html</link>
					<comments>https://netsis.es/blog/dominio-gal-que-es-y-requisitos.html#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Sun, 27 Sep 2026 19:23:12 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://netsis.es/blog/dominio-gal-que-es-y-requisitos.html</guid>

					<description><![CDATA[Qué compromiso con el gallego pide, si ayuda a posicionar en Galicia y cuándo tiene sentido frente al .es o el .com.]]></description>
										<content:encoded><![CDATA[<p>Tienes una empresa en Galicia y te preguntas si merece la pena el .gal, o si puedes registrarlo aunque tu web esté en castellano. Lo puede registrar cualquiera, viva donde viva. Lo que pide a cambio es un compromiso: que la web tenga un mínimo de contenido significativo en gallego, aunque tenga otros idiomas, o, si no lo tiene, que trate de la cultura gallega o ofrezca servicios pensados para la comunidad gallega. Una empresa de aquí con una versión de su web en gallego lo cumple sin hacer nada más.</p>
<p>Qué es el dominio .gal<br />
Es el dominio de internet de la lengua y la cultura gallegas, igual que el .cat lo es de la catalana. Lo gestiona la Asociación PuntoGal, una entidad sin ánimo de lucro, y se registra a través de los agentes que ella acredita. Funciona como cualquier otro dominio y sirve para la web, para el correo (info@tuempresa.gal) y para lo que necesites.</p>
<p>Quién puede registrarlo<br />
Cualquier persona o empresa, esté donde esté, y por orden de llegada, como un .com. Hay dos excepciones. Los nombres de los concellos gallegos están reservados para que los pida su ayuntamiento, y se aplican las limitaciones generales de ICANN, como los nombres de dos letras.</p>
<p>El compromiso con el gallego<br />
Esto es lo que diferencia al .gal. Según la ayuda oficial de dominio.gal, la web tiene que tener un mínimo de contenido significativo en gallego, aunque tenga otros idiomas. Si no tiene contenido en gallego, lo que publique tiene que estar relacionado con la cultura gallega o ser un servicio en línea dirigido a la comunidad gallega.<br />
En la práctica, una empresa gallega con su web también en gallego lo cumple de sobra. Si tu web es solo en castellano y no tiene nada que ver con Galicia, el .gal no es para ti, y nosotros no te lo recomendaríamos aunque esté libre.</p>
<p>¿Un .gal ayuda a posicionar en Galicia?<br />
Por sí solo, no. Google trata los dominios regionales como si fueran genéricos, igual que un .com, y pone de ejemplo el .london y el .bayern. No les da más peso para las búsquedas que se hacen desde esa región.<br />
Lo que te posiciona en Galicia es otra cosa: que tu web hable de lo que haces y de dónde lo haces, tener bien la ficha de Google Business y que otras webs de aquí te enlacen. El .gal ayuda de otra manera. Quien lo ve en los resultados sabe de dónde eres antes de entrar, y para mucha gente de aquí eso cuenta.</p>
<p>.gal, .es o .com</p>
<p>DominioQué dice de tiCuándo lo usaríamos</p>
<p>.galQue eres de aquí y que trabajas también en gallegoComo dirección principal si tu clientela es sobre todo gallega y tu web tiene versión en gallego<br />
.esQue trabajas en EspañaComo principal si vendes en toda España, con el .gal llevando a él<br />
.comNada del lugarSi vendes fuera de España, o para que nadie registre tu marca</p>
<p>Nosotros, a una empresa gallega, le registraríamos el .gal y el .es. Uno queda como dirección principal y el otro lleva a él con una redirección permanente. Lo que no conviene es publicar la misma web en los dos dominios a la vez, porque Google la ve como contenido duplicado y reparte la fuerza entre los dos.</p>
<p>Si ya tienes la web en un .es<br />
Puedes registrar el .gal y hacer que lleve a tu web actual, sin tocar nada más. Es lo más sencillo y no afecta a tu posicionamiento.<br />
Si lo que quieres es que el .gal pase a ser la dirección principal, se puede hacer, pero es una mudanza de dominio. Cada página antigua tiene que redirigir a su equivalente nueva, y hay que avisar a Google con la herramienta de cambio de dirección de Search Console. Aun haciéndolo bien, Google avisa de que las posiciones pueden moverse durante un tiempo, así que conviene planificarlo y no hacerlo en plena temporada.</p>
<p>Cuánto cuesta y cómo lo registramos<br />
Con nosotros, el .gal cuesta 45 € al año + IVA. Lo tramitamos nosotros y te queda el DNS gestionado y preparado para tu web, tu correo, Microsoft 365, Google Workspace o Cloudflare, junto con el resto de tus dominios. Si tienes dudas de si tu web cumple el compromiso con el gallego, lo miramos antes de registrarlo.<br />
Escríbenos desde el formulario de abajo con el nombre que buscas y te decimos si está libre. Tienes los precios del resto de dominios en dominios .gal, .es y .com.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://netsis.es/blog/dominio-gal-que-es-y-requisitos.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Skimmer en PrestaShop: cómo saber si están robando las tarjetas de tu tienda</title>
		<link>https://netsis.es/blog/skimmer-prestashop-robo-tarjetas.html</link>
					<comments>https://netsis.es/blog/skimmer-prestashop-robo-tarjetas.html#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Sun, 27 Sep 2026 19:23:12 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://netsis.es/blog/skimmer-prestashop-robo-tarjetas.html</guid>

					<description><![CDATA[Cómo detectar un skimmer en PrestaShop, por dónde entra y qué obligaciones tienes si lo encuentras.]]></description>
										<content:encoded><![CDATA[<p>Te llama un cliente porque le han cargado en la tarjeta compras que no hizo, y la usó hace poco en tu tienda. Luego llama otro. Miras la tienda y todo funciona: los pedidos entran, el pago sale bien y no hay nada roto. Eso es justo lo que busca un skimmer, un trozo de código que copia la tarjeta mientras el cliente la escribe y se la manda al atacante sin estropear nada, para que nadie lo note.<br />
Si lo sospechas, no esperes a estar seguro. Cada día que el código sigue ahí son más tarjetas, y si se confirma, el RGPD te da 72 horas desde que lo sabes para notificarlo a la Agencia de Protección de Datos cuando hay riesgo para tus clientes.</p>
<p>Cómo funciona un skimmer en una tienda online<br />
Hay dos variantes, según cómo cobre tu tienda.<br />
Si el cliente escribe la tarjeta en un formulario de tu propia web, el skimmer es un script que lee esos campos y los envía a otro servidor en el momento de pagar. El cobro se hace igual. El cliente no ve nada raro.<br />
Si tu pasarela te lleva a la página del banco para pagar, como hace el TPV de Redsys, el atacante no puede leer ese formulario. Lo que hace entonces es enseñar uno falso antes, con el mismo aspecto, y después dejar que el cliente siga hasta el pago de verdad. El cliente pone la tarjeta dos veces y lo toma por un fallo de la tienda. Pagar fuera de tu web reduce el riesgo, pero no lo elimina.<br />
Así fue la campaña de julio de 2022 contra PrestaShop. El propio proyecto avisó de que los atacantes metían un formulario de pago falso en la página de pedido aprovechando un fallo del núcleo.</p>
<p>Señales de que tu tienda puede tener un skimmer</p>
<p>Varios clientes, o el banco, te hablan de cargos fraudulentos en tarjetas que se usaron en tu tienda.<br />
En el proceso de pago aparece un formulario de tarjeta que antes no estaba, o se pide la tarjeta dos veces.<br />
Al pagar, la página carga scripts de dominios que no reconoces. Lo puedes ver tú mismo abriendo el pedido en una ventana privada y mirando la pestaña de red de las herramientas del navegador.<br />
Hay ficheros del tema o de módulos modificados en fechas en las que nadie trabajó en la tienda, o ficheros PHP con nombres sin sentido en la carpeta principal.<br />
Aparecen empleados en el back office que nadie dio de alta.</p>
<p>Ninguna prueba es definitiva por separado. Si ves dos, trátalo como un ataque hasta que se demuestre lo contrario.</p>
<p>Por dónde entran<br />
La puerta más conocida es el propio PrestaShop sin actualizar. El fallo de 2022, registrado como CVE-2022-31181, afecta desde la versión 1.6.0.10 hasta cualquier 1.7 anterior a la 1.7.8.7, que es la que lo corrige. Con él, un atacante podía ejecutar código en el servidor sin tener ninguna contraseña. Siguen funcionando muchas tiendas en versiones anteriores, así que la campaña sigue viva.<br />
La segunda puerta son los módulos. Una tienda suele tener decenas, de autores distintos, y algunos llevan años sin mantenimiento. Friends of Presta, una asociación de la comunidad, publica los fallos de seguridad que se van encontrando en módulos conocidos. Merece la pena cruzar esa lista con los tuyos.<br />
Y la tercera, las contraseñas robadas del back office o del hosting, que dan acceso sin necesidad de ningún fallo.</p>
<p>Qué hacer si lo encuentras</p>
<p>1. Guarda una copia antes de tocar nada<br />
Ficheros, base de datos y registros del servidor, fuera de la tienda. Con ellos se sabe desde cuándo estaba el código y qué pedidos pasaron por la página infectada, y eso es lo que te van a preguntar el banco y la Agencia de Protección de Datos.</p>
<p>2. Corta la fuga<br />
Quita el script o el formulario falso. Si todavía no sabes dónde está todo, desactiva el pago con tarjeta y deja los otros métodos mientras se limpia. Perder unas ventas un día sale más barato que seguir regalando tarjetas.</p>
<p>3. Averigua el alcance<br />
Los registros de acceso del servidor dicen cuándo se creó el fichero, desde dónde y cuántas visitas pasaron por el pago desde entonces. Con eso se acota qué clientes pueden estar afectados. Sin ese análisis solo queda avisar a todos.</p>
<p>4. Cierra la entrada y cambia las claves<br />
Actualiza PrestaShop y los módulos vulnerables, o quita los que no tengan arreglo, y cambia las contraseñas del back office, de la base de datos, del FTP y del hosting. Limpiar sin actualizar deja la puerta abierta, y actualizar sin limpiar deja el skimmer dentro. Hacen falta las dos cosas.</p>
<p>5. Avisa a quien toca<br />
A tu banco o a la pasarela de pago, que te dirán cómo proceder con las tarjetas. A la Agencia Española de Protección de Datos, en 72 horas desde que lo sabes, si hay riesgo para tus clientes. Se puede notificar con lo que tengas y completarlo después. Y a los propios clientes afectados cuando el riesgo para ellos es alto, que con tarjetas robadas lo suele ser.</p>
<p>Actualizar o rehacer la tienda<br />
Si tu tienda está en 1.7, lo razonable es subir como mínimo a la última 1.7.8, que es un salto dentro de la misma rama. Si está en 1.6, o si tiene muchos módulos sin mantener, puede que actualizar cueste casi lo mismo que montar una tienda nueva en PrestaShop 8 o 9. Nosotros lo valoramos siempre con una copia de ensayo antes de tocar la tienda real, y te decimos qué haríamos. Lo contamos en actualizar PrestaShop.</p>
<p>Cuánto cuesta<br />
La limpieza de una tienda PrestaShop con nosotros parte de 390 € + IVA. Incluye el análisis de los registros para saber si salieron datos y desde cuándo, que es lo que necesitas para decidir a quién avisar. Si luego quieres alojar la tienda con nosotros, nuestro hosting para PrestaShop lleva la vigilancia de ficheros incluida.<br />
Si crees que tu tienda está afectada, llámanos al 986 06 02 70. Es de las pocas situaciones en las que conviene llamar antes que escribir. Tienes todo el servicio explicado en malware en tiendas PrestaShop.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://netsis.es/blog/skimmer-prestashop-robo-tarjetas.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Cómo cambiar de hosting sin perder la web ni el correo</title>
		<link>https://netsis.es/blog/cambiar-de-hosting-sin-perder-web-ni-correo.html</link>
					<comments>https://netsis.es/blog/cambiar-de-hosting-sin-perder-web-ni-correo.html#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Sun, 27 Sep 2026 19:23:11 +0000</pubDate>
				<category><![CDATA[Blog]]></category>
		<guid isPermaLink="false">https://netsis.es/blog/cambiar-de-hosting-sin-perder-web-ni-correo.html</guid>

					<description><![CDATA[Qué se muda aparte de la web, qué se suele olvidar y cómo pasar el correo sin perder ningún mensaje.]]></description>
										<content:encoded><![CDATA[<p>Te suben el precio al renovar, la web va lenta o llevas una semana esperando a que te conteste el soporte. Quieres cambiarte, y lo que da miedo no es la web, es el correo. Se puede hacer sin cortes si sigues un orden: copiar sin tocar lo que tienes, probarlo todo en el hosting nuevo antes de que nadie lo vea, cambiar las DNS al final y pasar el correo en dos veces, una antes del cambio y otra después.<br />
Te contamos cómo lo hacemos nosotros y qué suele fallar, que casi nunca es la web.</p>
<p>Qué se muda en un cambio de hosting<br />
La web es lo que todo el mundo tiene en la cabeza, pero en la mayoría de empresas el hosting guarda bastante más:</p>
<p>Los ficheros de la web y su base de datos.<br />
Los buzones de correo con todo lo que tienen dentro, carpetas y enviados incluidos.<br />
La zona DNS del dominio, con los registros del correo (MX, SPF, DKIM y DMARC) y los de servicios externos, como Microsoft 365, Google Workspace o las verificaciones de Google.<br />
Los certificados SSL de la web y de los subdominios.<br />
Las tareas programadas, las cuentas de FTP y las redirecciones.</p>
<p>El dominio no hace falta moverlo. Para cambiar de hosting basta con cambiar hacia dónde apuntan sus DNS, y el traslado del dominio se puede hacer después, sin prisa, o no hacerlo nunca.</p>
<p>Lo que se suele olvidar<br />
Copiar ficheros es la parte fácil. Lo que da problemas es lo que no se ve.<br />
Los formularios de la web que envían el correo con la configuración del hosting viejo dejan de enviar el día que ese hosting se da de baja, y nadie se entera hasta que un cliente pregunta por qué no le contestasteis. Los registros DNS menos visibles, como el DKIM o las verificaciones de servicios, se pierden si se copia la zona a mano. Y si el dominio tiene DNSSEC activado, cambiar los servidores de nombres sin quitarlo antes deja el dominio sin resolver. Te quedas sin web y sin correo, en todas partes a la vez.<br />
El otro clásico es el correo guardado solo en el ordenador. Si alguien de la oficina tiene la cuenta configurada con POP, su correo antiguo está en su equipo y no en el servidor, así que no hay nada que migrar de él. Conviene saberlo antes, no después.</p>
<p>El orden que seguimos</p>
<p>1. Inventario de lo que hay<br />
Webs, bases de datos, buzones y lo que ocupa cada uno, la versión de PHP, la zona DNS completa y los servicios externos que dependen del dominio. Es la lista con la que se comprueba al final que no falta nada.</p>
<p>2. Copia sin tocar el origen<br />
Todo se copia al hosting nuevo con el viejo funcionando igual que siempre. Hasta el cambio final, tus clientes y tus correos siguen yendo al de siempre.</p>
<p>3. Prueba antes de que nadie lo vea<br />
La web se abre en el servidor nuevo con una dirección provisional y se revisa entera: páginas, formularios, pagos si es una tienda y el panel de administración. Si algo falla por una versión de PHP distinta, aparece aquí y no con los clientes dentro.</p>
<p>4. Baja el TTL de las DNS el día antes<br />
El TTL es el tiempo que el resto de servidores de internet recuerdan la dirección antigua de tu dominio. Si está en un día, el cambio tarda un día en llegar a todos. Bajándolo a unos minutos la víspera, el cambio llega casi enseguida.</p>
<p>5. Primera pasada del correo<br />
Se copian los buzones enteros, con todo el histórico, mientras siguen recibiendo correo en el servidor viejo. Es la pasada larga.</p>
<p>6. Cambio de DNS en un momento tranquilo<br />
Fuera de horas o en el momento que elijas tú. Durante un rato, unas visitas llegan al servidor viejo y otras al nuevo, y por eso los dos tienen que tener la misma web y los dos tienen que seguir recibiendo correo.</p>
<p>7. Segunda pasada del correo<br />
Recoge lo que llegó al servidor viejo mientras el cambio se extendía. Es corta y es la que evita que se pierda ningún mensaje.</p>
<p>8. Comprobación final<br />
Envío y recepción de correo desde fuera, formularios, certificados, tareas programadas y la lista del primer paso, punto por punto. El hosting viejo no se da de baja hasta que tú confirmas que todo va bien.</p>
<p>¿Afecta al posicionamiento en Google?<br />
Si las direcciones de las páginas no cambian, mover la web de servidor no cambia lo que Google ve. Google tiene una guía para este caso, el traslado sin cambio de URL, y lo trata como algo normal. Lo que sí puede notar es la velocidad, para bien si el hosting nuevo es más rápido. Donde se pierde posicionamiento es cuando se aprovecha la mudanza para cambiar direcciones sin redirigir las antiguas, y eso es otro trabajo que se planifica aparte.</p>
<p>Qué tienes que hacer tú<br />
Casi nada. Necesitamos el acceso al panel del hosting actual o, si no hay panel, el FTP y el acceso al correo, más el acceso a donde esté registrado el dominio para cambiar las DNS. Si no tienes esos accesos porque la web te la hizo una agencia que ya no existe, suele poder recuperarse. Quien figura como titular del dominio puede pedírselos al proveedor, y en eso te ayudamos.</p>
<p>Cuánto cuesta cambiarse a Netsis<br />
La migración es gratuita al contratar cualquiera de nuestros planes de alojamiento, y el hosting para WordPress empieza en 12 € al mes + IVA. Traemos la web, la base de datos y el correo, lo probamos todo antes del cambio y el día lo eliges tú. Si la web está infectada, antes de moverla hay que limpiarla, con presupuesto aparte, porque llevarse la infección al servidor nuevo no arregla nada.<br />
Si te lo estás pensando, escríbenos desde el formulario de abajo con dónde tienes la web y el correo ahora. Te decimos cómo lo haríamos y qué plan te encaja. Todo el proceso está en migración gratuita a Netsis.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://netsis.es/blog/cambiar-de-hosting-sin-perder-web-ni-correo.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
