Criar e gerir subdomínios IONOS - guia passo-a-passo

Vou mostrar-lhe, passo a passo, como criar um Subdomínio IONOS definir o DNS corretamente e testar o endereço corretamente. É assim que configuro os destinos, o SSL e o reencaminhamento, mantenho a estrutura clara e resolvo os erros típicos sem desvios.

Pontos centrais

Antes de começar, tenho em mente os seguintes factores de sucesso e trabalho com eles em sequência, de modo a que o subdomínio funciona de forma rápida e estável.

• ConfiguraçãoIniciar sessão, selecionar domínio, nomear subdomínio
• DNSDefinir corretamente o registo A, AAAA ou CNAME
• SSLAtivar certificado por subdomínio
• SEOSitemaps, estrutura clara, sem conteúdos duplicados
• TestesAguardar a propagação, verificar o alvo

Mantenho nomes claros, registos DNS limpos e uma SSL no foco. Isto permite-me delimitar claramente os serviços, os testes e as actuações ao vivo. Documento todas as alterações para poder adaptar-me mais rapidamente mais tarde. Planeio a estrutura do subdomínio de forma a facilitar as extensões posteriores. Verifico a acessibilidade de vários locais antes de promover ativamente os conteúdos.

O que é um subdomínio? Brevemente explicado

Um subdomínio estende o domínio principal com um nome de anfitrião prefixado, tal como blog. Isto permite-me separar conteúdos, serviços ou equipas em termos técnicos e organizacionais sem ter de comprar um novo domínio. Os exemplos são blog.meinedomain.de, shop.meinedomain.de ou dev.meinedomain.de para testes. A ideia: encapsulo funções e posso controlar alvos, SSL e avaliação de forma independente. Se quiser ler os termos e as opções de forma condensada, encontrará um resumo neste definição de subdomínio curto conhecimentos básicos adicionais.

Criar um subdomínio IONOS: passo a passo

Inicio sessão na minha conta de cliente e abro Domínios e SSL, depois selecciono o Domínio de. Na área do subdomínio, clico em Criar subdomínio e introduzo um nome curto, como blogue, loja ou cliente. Especifico como destino o diretório Web do sítio principal ou uma pasta separada para uma aplicação autónoma. Para serviços externos, defino um CNAME ou um registo A para o endereço de destino nas definições de DNS em vez de um destino de pasta. Depois de guardar, aguardo a propagação do DNS, testo o subdomínio no browser e verifico o estado e o SSL na visão geral.

Com o IONOS, utilizo estes tipos de alvos em função do objetivo: 1) Diretório do espaço Web para o conteúdo próprio, 2) Reencaminhamento (HTTP/HTTPS) para outro URL, 3) Ligação a uma aplicação ou a um sítio, se estiver ligado um kit de construção/loja, 4) Puramente baseado no DNS, se for endereçado um serviço externo. Mantenho a estrutura do caminho e as autorizações no espaço Web consistentes para que as implementações sejam reproduzíveis. Activei especificamente a proteção de acesso para as instâncias de teste, de modo a que os motores de busca e os utilizadores não aterrem acidentalmente nelas.

Definir corretamente os destinos e registos DNS

Para conteúdos Web, normalmente ligo o subdomínio através de A-Record para um endereço IPv4 ou através de um registo AAAA para um endereço IPv6. Se o serviço de destino for executado externamente, costumo definir um CNAME que aponta para o anfitrião do fornecedor. Um valor TTL sensato é importante para que as alterações tenham efeito rapidamente e as alterações subsequentes não demorem uma eternidade. Verifico nas definições de DNS se o nome do anfitrião, o tipo de registo e o destino correspondem exatamente. Se quiser ler as sequências de passos de forma compacta, utilize o guia para Definições de DNS para IONOS como um lembrete.

Planeio a estratégia TTL: em fases com muitas alterações, defino um TTL mais baixo (por exemplo, 300-900 segundos) e, após a estabilização, aumento-o novamente para utilizar o caching. O A e o AAAA devem apontar para o mesmo sistema em paralelo, caso contrário haverá um comportamento diferente consoante o cliente. Evito CNAMEs quando preciso de controlo granular sobre A/AAAA ou quero minimizar a latência. Se for utilizado um CDN ou um proxy inverso, aponto o subdomínio para o fornecedor através de CNAME e documento internamente os IPs originais.

Para configurações complexas, delego subzonas: Defino registos NS para, por exemplo, dev.mydomain.com para outros servidores de nomes se uma equipa gerir o ambiente de desenvolvimento de forma independente. Verifico se não existe autoridade duplicada (sem registos concorrentes na zona superordenada). Também presto atenção aos registos CAA na zona principal se a emissão de certificados for restrita; o subdomínio herda estas regras.

Configurar corretamente os redireccionamentos

Faço uma distinção clara entre 301 (permanente), 302/307 (temporário) e 308 (permanente, método de retenção). Para subdomínios que apenas devem ser redireccionados, utilizo um redireccionamento do lado do servidor e deixo os caminhos e as cadeias de consulta passarem inalterados, se possível. Evito redireccionamentos mascarados porque dificultam o SSL, a SEO e a segurança. Quando me desloco, planeio matrizes de redireccionamento: fontes de subdomínio, URLs de destino, códigos de estado, tempo de execução. Mantenho a cadeia plana (máximo de um salto) para não sobrecarregar o desempenho e o orçamento de rastreio.

Subdomínios curinga e acesso FTP

Se eu encaminhar muitos subdomínios dinamicamente, defino um Cartão selvagem como *.mydomain.com e apontá-los para um destino padrão. Desta forma, mesmo os anfitriões que ainda não foram criados acabam numa página significativa ou num projeto abrangente. Para o acesso FTP, gosto de utilizar ftp.mydomain.com e armazenar um CNAME no endereço técnico do servidor para que as ferramentas possam reconhecer facilmente o anfitrião. Esta convenção facilita o trabalho em equipa e documenta as intenções no nome do anfitrião. Também mantenho nomes como dev, staging ou test consistentes para separar claramente os estados dos testes.

Para os curingas, presto atenção ao SSL: dependendo da tarifa e do método de validação, é necessário um certificado curinga, caso contrário a ligação HTTPS falhará. Verifico se determinados anfitriões devem ser excluídos, por exemplo, se shop.mydomain.com aponta para um fornecedor externo. Os curingas são poderosos, mas utilizo-os especificamente para evitar sobreposições não intencionais entre os anfitriões codificados e os "catch-all".

Utilizar o correio eletrónico em subdomínios de forma sensata

Se precisar das minhas próprias caixas de correio para um subdomínio (por exemplo, support.mydomain.com), configuro registos MX dedicados. Se os serviços forem enviados a partir de um subdomínio (por exemplo, newsletter.mydomain.com), adiciono registos SPF e configuro DKIM/DMARC da mesma forma que para o domínio principal. Isto mantém a capacidade de entrega estável e separo corretamente as identidades dos remetentes. Evito utilizar subdomínios produtivos da Web para correio eletrónico ao mesmo tempo, para poder encapsular os serviços de forma limpa e evitar conflitos com registos DNS.

Segurança e proteção do acesso

Eu troco SSL consistentemente activos para cada subdomínio e redireccionam automaticamente o HTTP para HTTPS. Para ambientes internos, também defino a autenticação básica, as restrições de IP ou o acesso VPN para impedir os motores de busca e o acesso não autorizado. Verifico conteúdos mistos, HSTS e conjuntos de cifras modernos para evitar avisos do browser. Para as API, guardo as regras CORS por subdomínio para que os frontends tenham acesso controlado. Quando faz sentido, isolo sessões e cookies por anfitrião para minimizar os riscos de domínios de cookies muito utilizados.

Desempenho, armazenamento em cache e CDN

Decido, para cada subdomínio, se uma CDN ou proxy invertido oferece valor acrescentado: conteúdo estático, alcance internacional, proteção DDoS. Para as caches activas, planeio estratégias de purga e versões (nomes de ficheiros com hash), para que as implementações sejam efectuadas de forma limpa, sem necessidade de atualizar o browser. No lado do servidor, utilizo Etags/Last-Modified e cabeçalhos de controlo de cache sensatos. Separo as aplicações de computação intensiva (por exemplo, API) dos subdomínios de conteúdo para que as caches funcionem eficientemente e as cargas não interfiram umas com as outras.

Implementar casos de utilização típicos de forma eficiente

Para conteúdos com a sua própria tonalidade, crio blog.meinedomain.de e executo um CMS. Encapsulo uma loja em shop.mydomain.com para que a lógica de checkout e de produto seja executada separadamente. Coloco um portal do cliente em kunden.meinedomain.de e restrinjo o acesso através de funções e regras de IP. As campanhas são atribuídas a aktion.meinedomain.de para que o acompanhamento, o SEO e o conteúdo permaneçam independentemente mensuráveis. Estaciono os estados de desenvolvimento em dev ou staging para poder testar com segurança as novas funções antes de as colocar em funcionamento.

Para APIs, configuro api.meinedomain.de, tenho em conta CORS, limites de taxa e versionamento de caminho claro (por exemplo, /v1/). Para ferramentas internas, escolho subdomínios de administração ou de intranet e protejo-os fortemente. Para os media, utilizo media ou cdn para que os browsers carreguem em paralelo e as estratégias de cache tenham efeito. Os subdomínios de curta duração ajudam nas experiências e nas pré-visualizações de funcionalidades, que elimino novamente após a conclusão para manter a estrutura enxuta.

SEO para subdomínios: melhores práticas

Eu escolho curto, falando Nomes como blogue, loja ou faq e manter a estrutura coerente. Cada subdomínio tem o seu próprio certificado SSL, o seu próprio mapa do sítio e uma propriedade separada na Consola de Pesquisa. Mantenho as ligações internas limpas do ponto de vista temático para que os rastreadores e os utilizadores compreendam a finalidade de cada endereço. Evito a duplicação de conteúdos utilizando canónicas claras, redireccionamentos limpos e conteúdos exclusivos. Para conteúdos internacionais, defino um subdomínio com hreflang para cada língua ou utilizo subpastas se a estrutura tiver de ser gerida centralmente.

Certifico-me de que os subdomínios, como staging ou dev, estão definidos como noindex e protegidos por autenticação. Quando me desloco entre subdomínios e diretórios, planeio redireccionamentos, actualizo mapas de sites e verifico os ficheiros de registo para detetar erros de rastreio. Separo as propriedades de rastreio por subdomínio, mas mantenho um painel de controlo geral para reconhecer as tendências entre departamentos. Deixo deliberadamente a pesquisa interna e as páginas de filtro fora dos mapas do sítio para manter o índice limpo.

Instalar o WordPress num subdomínio

Para um projeto independente, crio o meu próprio Diretório atribuo-lhe o subdomínio e instalo aí o WordPress. Se, em vez disso, utilizar um multisite, ativo os subdomínios na configuração da rede e verifico antecipadamente o DNS universal. Executo a cache, a otimização de imagens e as actualizações separadamente para cada subdomínio, para reduzir ao mínimo as fontes de erro. Se precisar de uma folha de consulta para a configuração básica do domínio, consulte este guia para Configurar o domínio IONOS e complementa os passos para os subdomínios. Isto significa que a manutenção pode ser planeada e que o desempenho de cada subdomínio permanece sempre consistente.

Para instalações individuais, certifico-me de que tenho as minhas próprias bases de dados ou prefixos claros, diretórios de carregamento separados e tarefas cron independentes. Defino corretamente o URL do sítio e o URL inicial no subdomínio e verifico se não existem ligações absolutas antigas do domínio principal. Nas configurações de vários sites, testo primeiro os novos subdomínios na rede antes de os ativar externamente. Para instâncias de teste, desativo a indexação, renovo os sais, bloqueio os motores de busca e mantenho os dados de acesso separados.

Governação, designação e cooperação

Defino um esquema de nomes e mantenho-o de forma coerente: funcional (api, media, shop), organizacional (team, hr) ou geográfico (eu, us), mas não misto. Documento as alterações de forma permanente: quem criou que registo DNS, quando, porquê e com que TTL. Para equipas maiores, delego subzonas em servidores de nomes dedicados e permissões de escrita seguras para que nem todos possam fazer alterações em todo o lado. Estabeleço processos de revisão para DNS, SSL e redireccionamentos para evitar interrupções e danos de SEO.

Testes, propagação e diagnóstico

Verifico a resolução a partir de diferentes redes e dispositivos. Antes da mudança global, testo localmente através do mapeamento do ficheiro hosts para verificar as configurações do servidor. Distingo se um erro tem origem no DNS (NXDOMAIN, IP incorreto), na rede (timeout) ou na aplicação (404/500). Para SSL, comparo a cadeia de certificados, a cobertura do anfitrião e a validade. Monitorizo o tempo até à propagação total e não planeio alterações visíveis durante os picos de carga ou pouco antes do lançamento da campanha.

Resolução de problemas: Resolva rapidamente erros comuns

Se o novo endereço não aparecer, verifico primeiro DNS para erros de digitação, tipos de registo incorrectos ou destinos em falta. É realista esperar algumas horas, até 48 horas, porque a distribuição global demora algum tempo. Limpo a cache do browser e as caches do DNS local para eliminar entradas antigas. Para uma verificação externa, testo a resolução em vários locais e verifico se o A ou o CNAME estão a responder corretamente. Se o SSL não estiver a funcionar, reinicio a emissão do certificado para o subdomínio e verifico se o anfitrião está acessível ao público.

No caso de erros 404, verifico se o diretório está ligado corretamente e se as regras .htaccess são eficazes. Se o servidor devolver 403, os direitos ou o índice do diretório são frequentemente afectados. Se entregar um pedido 421/421 mal direcionado, o anfitrião virtual não corresponde ao pedido SNI. Se o CNAME e o registo A existirem simultaneamente no mesmo subdomínio, elimino os conflitos. Para os erros DNSSEC, verifico as assinaturas e a cadeia; para as entradas CAA, ajusto os emissores para que os certificados sejam novamente emitidos.

Funcionamento, controlo e manutenção

Configuro verificações de tempo de atividade para cada subdomínio crítico, monitorizo os dados de expiração de SSL e mantenho-me atento às taxas de latência e de erro. As implementações são controladas por scripts e reproduzíveis, de modo a que os rollbacks sejam possíveis rapidamente. Planeio as janelas de manutenção, apresento as páginas de manutenção de forma clara e mantenho os redireccionamentos prontos para emergências. Para os conteúdos, mantenho um plano de backup separado para cada subdomínio, para que os restauros possam ser efectuados com precisão e os SLAs possam ser cumpridos.

Gerir e eliminar sem falhas

No menu do subdomínio, altero a opção Objetivoquando um serviço muda ou é utilizado um novo diretório. Antes de os remover, verifico as dependências, como o encaminhamento de correio eletrónico, os redireccionamentos, o rastreio e os mapas de sítios. Desactivo os redireccionamentos de forma organizada, protejo os conteúdos e defino redireccionamentos 301 temporários, se necessário. Isto mantém a orientação do utilizador intacta enquanto limpo ou faço a fusão de subdomínios. Uma breve documentação evita que os antigos hosts sejam acidentalmente reactivados mais tarde.

Após os encerramentos, mantenho os redireccionamentos 301 durante tempo suficiente, actualizo as ligações e asseguro que os URLs antigos desaparecem dos mapas de sites. Limpo os grupos de segurança, os acessos e os cronjobs para que não fiquem processos órfãos. Na Consola de Pesquisa, só removo as propriedades que se tornaram obsoletas se os sinais já não forem necessários a longo prazo.

Comparação: IONOS e alternativas

Para projectos quotidianos, o Administração da IONOS para subdomínios, SSL e DNS padrão. As configurações sofisticadas com muitos registos, redireccionamentos especiais e serviços externos beneficiam de fornecedores com uma funcionalidade DNS muito ampla. Interfaces claras, registos de alterações e apoio rápido se as entradas forem críticas são importantes. Pondero a conveniência em relação à flexibilidade e decido de acordo com a dimensão do projeto e a estrutura da equipa. A tabela seguinte apresenta uma comparação compacta dos pontos-chave para facilitar a categorização.

Fornecedor	Gestão de subdomínios	Flexibilidade do DNS	Suporte
webhoster.de	Muito extensa	Excelente	24/7 Premium
IONOS	Fácil a médio	Bom	Bom nível
Concorrente X	Médio	Médio	Padrão

Brevemente resumido

Crio subdomínios no IONOS de uma forma direcionada, defino os Registos e controlar cuidadosamente a acessibilidade. A nomenclatura clara, o SSL dedicado e os mapas de sítios limpos tornam a administração e a SEO calculáveis. Para o WordPress, separo constantemente os projectos e mantenho a cache e as actualizações separadas para cada subdomínio. Em caso de interrupções, verifico o DNS, a cache e o certificado antes de alterar os objectivos ou definir redireccionamentos. Isto garante que a estrutura permanece fiável, que o conteúdo carrega rapidamente e que cada subdomínio cumpre o seu objetivo sem perdas por fricção.