[Résolu] Sous-dossiers ou sous-domaines pour autres langues? Vos cons

Bonjour à tous,

J'aimerais avoir votre point de vue avant de commencer de longs travaux.

J'ai un site en PHP qui tourne très bien, mais celui-ci utilise des cookies pour changer de langue, les fichiers langue sont inclus dans l'index, affichage super rapide, mais pas bon pour le positionnement dans Google me dit-on.

La solution semble-t-il est d'adopter une structure où les versions traduites sont accessibles sans passer par des URL compliquées.

Donc, d'abord, changer la structure puis, étudier l'URL rewriting.

Que me conseilleriez-vous et pourquoi ?
Les critères sont:
- mettre toutes les chances de son côté pour être "Google Friendly".
- la structure qui laisse le plus de possibilités pour de futurs développements.

Sous-domaines

www.monsite.eu (défaut=> français)
www.español.monsite.eu
www.english.monsite.eu

ou

Sous-dossiers

www.monsite.eu (défaut => français)
www.monsite.eu/español
www.monsite.eu/english

Merci beaucoup

Les extensions étrangères pour votre nom de domaine sont toutes prises ?

Arvel a écrit :
Les extensions étrangères pour votre nom de domaine sont toutes prises ?

+1

Sinon via un *.htaccess
Modifié par niuxe (14 Dec 2013 - 16:07)

niuxe a écrit :

Les extensions étrangères pour votre nom de domaine sont toutes prises ?

niuxe a écrit :

+1

-1

Attention, c'est une très mauvaise pratique, les extensions de pays identifient un pays, non pas une langue! Avoir une extension pour un pays signifie qu'on s'adresse spécifiquement à la population de ce pays. De plus si un projet grossi, cette erreur risque de devenir très vite un casse-tête. Par contre si on a effectivement plusieurs nom de domaines de pays, ceux-là peuvent définir: un langue par défaut différente, un ensemble de langue utilisable différent

@Tropiques,
généralement on utilise indique plutôt la langue par un paramètre en GET que comme sous-domaine. Le sous-domaine étant moins dynamique et pouvant avoir des effets de bord non désiré (same-origin policy). Toutefois ce n'est pas obligatoire.
On indique plus volontiers les langues par leur locales: fr, en, fr-CA, etc. que par leur nom complet. De nouveau pour des raisons pratiques: pratiques courante et reconnue, interopérabilité, encodage, etc.

donc dans ton cas cela donnerait:

www.monsite.eu/fr
www.monsite.eu/es
www.monsite.eu/en

Pour le référencement on prendra garde à renseigner l'url canonique pour la langue par défaut, ou effectuer une redirection:

www.monsite.eu => www.monsite.eu/fr
Modifié par kustolovic (14 Dec 2013 - 17:03)

a écrit :
Attention, c'est une très mauvaise pratique, les extensions de pays identifient un pays, non pas une langue!

+1. C'est pour cette raison que certains croient encore que .ch = forcément allemand. Les romands et les tessinois les remercient encore.
ET je suppose que les belges ont le même problème... et les autres pays du monde qui ont plusieurs langues nationales officielles aussi.

JE vote aussi pour les dossiers plutôt que les domaines, et pour les codes de deux lettres.

Pour ma part j'ai aussi un site multilingue où j'ai opté pour la version dossiers et avec une réécriture.
monsite.com/fr/nom-de-page correspond en fait en interne à monsite.com/nom-de-page?language=fr.
ET je pense que c'est une bonne solution parce que ça permet à l'utilisateur de changer très facilement de langue. C'est le même script php qui gère toutes les langues, les textes sont stockés en base ou dans des fichiers. En tout cas, il faut à tout prix éviter le comportement extrêmement dérangeant mais malgré tout encore très répandu de ne pas avoir la même page / revenir systématiquement sur la page d'accueil quand on change de langue.

L'avantage des dossiers plutôt que les domaines, c'est que
1 - IL n'y a rien à faire avec les DNS
2 - ON peut tout fourrer dans le même vhost sans être obligé de bidouiller (parce que souvent dans les panels, un sous-domaine = un autre vhost)

Par contre, question: ça:

a écrit :
Pour le référencement on prendra garde à renseigner l'url canonique pour la langue par défaut, ou effectuer une redirection

1 - Est-ce que c'est vraiment important ?
2 - Comment faire s'il n'y a pas réellement de langue par défaut ? Je veux dire par là que par exemple si la langue n'est pas spécifiée dans l'URL (p.ex. monsite.com/page par opposition à monsite.com/fr/page), alors je détermine la langue la plus appropriée à envoyer en me basant sur $_SERVER['HTTP_LANGUAGE'] ? Si je trouve du fr, j'envoie le françAis, si je trouve du es l'espagnol, etc. et si c'est une locale que je ne connais pas, j'envoie l'anglais.
Du coup la même URL monsite.com/page peut s'afficher en français ou en anglais, suivant qui la visite et comment son navigateur me renseigne.
Est-ce qu'il faudrait alors décider que si la langue n'est pas spécifiée alors toujours anglais nécessairement ? Ce serait dommage parce que du coup, les françAis qui tapent monsite.com/ sans le fr tomberaient systématiquement sur l'anglais, c'est pas cool.

QuentinC a écrit :

+1. C'est pour cette raison que certains croient encore que .ch = forcément allemand. Les romands et les tessinois les remercient encore.

Je suis suisse romand aussi, et donc je m'énerve aussi à chaque fois , et les sites que je fais en français on bien une extension .ch, et non .fr, et si je dois internationaliser pour la suisse allemande, ce sera toujours .ch, mais en allemand.

QuentinC a écrit :

1 - Est-ce que c'est vraiment important ?
2 - Comment faire s'il n'y a pas réellement de langue par défaut ? Je veux dire par là que par exemple si la langue n'est pas spécifiée dans l'URL (p.ex. monsite.com/page par opposition à monsite.com/fr/page), alors je détermine la langue la plus appropriée à envoyer en me basant sur $_SERVER['HTTP_LANGUAGE'] ? Si je trouve du fr, j'envoie le françAis, si je trouve du es l'espagnol, etc. et si c'est une locale que je ne connais pas, j'envoie l'anglais.
Du coup la même URL monsite.com/page peut s'afficher en français ou en anglais, suivant qui la visite et comment son navigateur me renseigne.
Est-ce qu'il faudrait alors décider que si la langue n'est pas spécifiée alors toujours anglais nécessairement ? Ce serait dommage parce que du coup, les françAis qui tapent monsite.com/ sans le fr tomberaient systématiquement sur l'anglais, c'est pas cool.

Effectivement, je n'étais pas allé aussi loin dans le détail. pour être plus précis:

Google sanctionne les sites qui offrent le même contenu sur deux URL distinctes (les points sont répartis), et demande à ce que l'on préfère une URL. Cela peut se faire soit par une redirection, soit par l'ajout de la balise <link rel="canonical" href=""/>, soit par l'envoi d'en-têtes HTTP => https://support.google.com/webmasters/answer/139394?hl=fr

Effectivement au lieu de répondre juste la langue par défaut sur l'URL de base, on peut se baser sur une détection, ainsi que sur toute page du site, en choisissant l'ordre de priorité, par exemple:
1) langue dans l'URL
2) langue en session/cookie
3) langue trouvée dans HTTP_ACCEPT_LANGUAGE
4) (géolocalisation : rarement fait mais ça m'est arrivé)
5) langue par défaut
Toutefois, il est très courant de réintroduire la navigation par langue dans l'URL, soit par une redirection, soit en ajoutant le bon paramètre dans les urls de la page. car avec ainsi on s'assure que:
– l'historique reste consistant, je retrouverai bien la même page.
– Le copier/coller de l'URL mènera bien toujours à la même ressource. Et donc si j'envoie un lien sur un forum/media-social/mail, je m'assure qu'ils voient bien la même page. (j'ai déjà eu des déboires à cause de cela)
– Certaines ressources peuvent ne pas exister dans une langue
Modifié par kustolovic (15 Dec 2013 - 01:01)

@kusto
@QuentinC

Merci pour vos réponses et bravo, il est très plaisant de lire des 'posts' bien rédigés.

(Parenthèse: oui, je peux confirmer, le problème que vous évoquez énverve aussi les belges )

J'ai étudié presque seul html/CSS/Javascript/PHP/Mysql puis Mysqli/Apache/Photoshop ect... , je croyais en avoir fini et voilà qu'apparaissent les problèmes de positionnement, de référencement, de contenu dupliqué, de structure de site et d'internationalisation dont je ne savais rien. J'ai pris certains noms de domaine avec extension nationale en plus, de manière prématurée, et je ne vois plus que des points d'interrogation. J'ai volontairement limité ma question à la structure, afin que ça ne parte pas dans tous les sens.

Pour avancer dans ce sujet, pourriez-vous m'éclairer ?

J'aimerais adopter la solution 'www.monsite/langue' que vous proposez, faut-il faire :

www.monsite.eu => un index.php et juste le code nécessaire pour rediriger (header('loc...')) vers le sous-répertoire voulu grâce au $_GET['LANGUAGE']
www.monsite.eu/fr => un autre index.php, toutes les pages 'fr', tous les dossiers ( photo etc ... )
www.monsite.eu/es => un autre index.php, toutes les pages 'es', tous les dossiers ( photo etc ... )
www.monsite.eu/en => un autre index.php, toutes les pages 'en', tous les dossiers ( photo etc ... )
un peu comme si tous les sous-répertoires étaient des sites séparés ?

ou

www.monsite.eu => avec : un seul index.php pour tout, et faire 'sauter' pour aller chercher les pages dans le sous-répertoire /fr, /es ou /en ... mais là je ne vois pas comment, ni comment naviguer dans une langue avec un index qui se trouverait dans le répertoire parent.

Ou serait-ce ni l'un, ni l'autre ?

Merci encore

a écrit :

Google sanctionne les sites qui offrent le même contenu sur deux URL distinctes (les points sont répartis), et demande à ce que l'on préfère une URL. Cela peut se faire soit par une redirection, soit par l'ajout de la balise <link rel="canonical" href=""/>, soit par l'envoi d'en-têtes HTTP => https://support.google.com/webmasters/answer/139394?hl=fr[/url]

Avec canonical je n'ai encore pas bien compris le truc. D'après ce que j'ai compris, il ne faut donner l'indication que si on est sur une « mauvaise » page, mais surtout, surtout pas si on est sur la « bonne ».
Est-ce juste ou faux ?
Ensuite, faut-il préférer la meta ou l'enn-tête HTTP ?

La chose à remarquer c'est qu'en fait j'ai l'inverse: je ne propose pas le même contenu sur deux URL différentes, mais deux contenus sur la même URL.
Dans ce cas, la solution la plus rationnelle est-elle la redirection systématique ?

L'URL sans précision de la langue peut être pratique pour les e-mails automatiques par exemple.
Vous avez perdu votre mot de passe ? allez sur machin.com/pass-perdu/ est plus facile que de checker la langue de tous les utilisateurs et de fournir l'uRL exacte.

a écrit :
Toutefois, il est très courant de réintroduire la navigation par langue dans l'URL, soit par une redirection, soit en ajoutant le bon paramètre dans les urls de la page. car avec ainsi on s'assure que: – l'historique reste consistant, je retrouverai bien la même page.

– Le copier/coller de l'URL mènera bien toujours à la même ressource. Et donc si j'envoie un lien sur un forum/media-social/mail, je m'assure qu'ils voient bien la même page. (j'ai déjà eu des déboires à cause de cela)

Bonne remarque. En fait je le faisais déjà, même si on se connecte sur monsite.com/page, tous les liens du menu par exemple sont en monsite.com/fr/xxx. Mais il n'y a pas de redirection; simplement, dès qu'on clique sur un lien interne au site alors on passe dans le dossier de la langue actuelle.

a écrit :
– Certaines ressources peuvent ne pas exister dans une langue

J'avais oublié ce fait ! Du coup ça m'amène à une autre question.

J'ai un forum où il y a une section en français et une section en anglais.
Normalement c'est bien séparé; si on navigue en français, on ne peut normalement pas arriver sur un topic anglais et inversément.

Par contre la base de donnée derrière est commune. Ce qui fait que si on tape
monsite.com/fr/forum1/topic123
et
monsite.com/en/forum1/topic123
On tombe sur la même page avec les mêmes posts; l'interface (connexion/répondre/citer/éditer/etc. est adaptée et différente, mais évidemment pas les posts eux-mêmes.
Est-ce qu'il y a risque de contenu dupliqué dans ce cas ? sachant que normalement, à moins d'un bug ou d'une saisie manuelle, on ne peut pas tomber sur le topic anglais si on était en français.

@Tropiques:
Les questions que tu poses là, hormis la question de la redirection où pas sur laquelle je suis aussi curieux, sont plus une question de cuisine interne que de référencement à proprement parler je pense.
Il faut que tu t'organises selon ce qui te paraît le plus pratique, le plus fonctionnel et le plus maintenable. Tu peux tout autant avoir un index.php général qui redispatch tout, ou des sous-dossiers ayant des arborescences à peu près parralèles.

Perso je pense que l'index.php qui dispatch tout est le mieux. Mais ça dépend de plein de choses: si le contenu offert dans les multiples langues est plutôt identique ou plutôt totalement différent, comment les données sont stockées (plusieures bases ou une seule ? plusieurs serveurs avec un par langue ?)

De mon côté je reste malgré tout un très très petit site; j'ai un seul serveur et une seule base de données pour toute les langues et ça suffit largement. Donc ça me paraît plus naturel d'avoir un seul et unique fichier index.php racine qui gère tout et qui divise le travail.
Mais si j'avais plusieurs sites et/ou plusieurs bases divisées par langue et/ou des particularités spécifiques à prendre en compte seulement pour telle ou telle langue qui ne sont pas gérables en base/fichiers, peut-être que ce serait effectivement mieux d'avoir des sous-arborescences parralèles.
A la base il me semble que c'est plutôt quelque chose à éviter, le copier-coller est l'ennemi n°1 du programmeur.

@QuentinC

Oui, tu as tout à fait raison pour la cuisine interne, mais comme je me heurte à de nombreux nouveaux problèmes en même temps, je voulais faire le point sur les différentes structures de site possibles, vu que, selon que je déciderai de travailler avec une extension de pays comme .es ou de garder un domaine générique comme .eu , cela aura une influence sur la structure générale du site.

D'ailleurs, j'ai trouvé comment faire pour avoir les langues dans des sous-répertoires différents et y accéder depuis le répertoire parent:

si cookie == fr

$include = array("accueil"=>"[#blue][b]fr/[/b][/#]xxx.php", ...etc ... toutes tes pages );

si cookie == es

$include = array("accueil"=>"[#blue][b]es/[/b][/#]xxx.php", ...etc... toutes tes pages );

il suffit de préfixer la page avec le nom du répertoire fr/ ou es/ dans l'array. Ca semble fonctionner super bien. Dans le répertoire parent je laisse, index, css, connexion BDD et tous les fichiers qui ne sont spécifiques à une langue.

Par contre je ne parviens pas à avoir le paramètre "langue" dans l'URL, pourtant je le passe en GET au moment où l'on clique pour changer de langue :

echo "<a href='index.php?page=es/xxx&language=es'>Español<div id='drapeau'></div></a>"; 

Aurais-tu une idée ?

Merci

echo "<a href='index.php?page=es/xxx&language=es'>Español<div id='drapeau'></div></a>";

Comme ça rapidement en 10 secondes, il y a deux choses qui m'interpellent dans ce code :
1 - Les valeurs des attributs entre apostrophes au lieu des guillemets. J'ignore si c'est reconnu en standard mais il me semble que normalement ça ne se fait pas. Ca me paraît être un peu « dirty ».
2 - Entre deux paramètres on met & amp; et non pas & tout court (ne pas tenir compte de l'espace, il est là pour contrer un bug du forum). Cela est dû au fait que le & seul peut être interprété comme une entité avec ce qui suit. Je pense qu'une partie du problème peut être là.


Pendant que j'y suis, critique d'ordre générale: j'éviterais les index.php?page=XXX&lang=YY et je les remplacerais par des réécritures en ordre (/es/page => index.php?lang=es&page=page). C'est utile de le faire très vite dans tes tests, ça t'éviteras de changer 12 fois et/ou de jongler entre des .htaccess différents en environnement de test et en production. ET on a déjà pu prouver que les URL naturelles sans paramètres apparents étaient mieux référencées et un peu moins sensibles aux petites attaques de bas étage.
En ce qui concerne les attaques, voir le ?page=XXX incite à vouloir essayer des trucs du genre ?page=../config/db.php (et ça marche sur certains sites peu soucieux). Ca ne veut pas dire qu'il ne faut pas s'en protéger si on met en place des réécritures, mais on s'y expose moins.
Modifié par QuentinC (16 Dec 2013 - 20:36)

@QuentinC
Bonjour,

En ce qui concerne l'utilisation de ' ou " dans les attributs, je n'ai rien trouvé sur le net à ce sujet.
En tout cas PHP manuel propose l'une ou l'autre solution au choix. L'avantage de commencer les chaînes avec " est qu'il n'est pas nécessaire de déparser les $variables, celles-ci sont interprétées dans la chaîne... mais je chercherai encore.

Ok pour le rewriting, je m'y mets...

Il y a juste une chose dont je ne suis pas sûr:

Tu as changé l'ordre des variables dans mon exemple,

index.php?lang=es&page=page

au lieu de

index.php?page=page&lang=es

Cela aurait-il une importance en vue du rewriting ?

Première fois que je vois l' attaque dont tu parles : ../config/db.php.
Comment s'appelle-t-elle et aurais-tu une doc à me renseigner à ce sujet ?

Merci

Tropiques a écrit :

En ce qui concerne l'utilisation de ' ou &quot; dans les attributs, je n'ai rien trouvé sur le net à ce sujet.
En tout cas PHP manuel propose l'une ou l'autre solution au choix.

QuentinC parlait des guillemets pour les attributs HTML, mais les deux sont parfaitement valides, les guillemets doubles sont juste beaucoup plus courants:

<option disabled> <!-- valide HTML -->
<option disabled=disabled> <!-- valide HTML -->
<option disabled="disabled"> <!-- valide HTML & XHTML -->
<option disabled='disabled'> <!-- valide HTML & XHTML -->

edit: Pour la spec (HTML5) : http://www.w3.org/TR/html5/syntax.html#attributes-0
Modifié par kustolovic (17 Dec 2013 - 10:42)

a écrit :
Tu as changé l'ordre des variables dans mon exemple,
index.php?lang=es&page=page
au lieu de
index.php?page=page&lang=es
Cela aurait-il une importance en vue du rewriting ?

Non, absolument aucune si tu fais du rewriting.
Par contre peut-être que ça en a une sur le référencement si tu n'en fais pas.

a écrit :
Première fois que je vois l' attaque dont tu parles : ../config/db.php.
Comment s'appelle-t-elle et aurais-tu une doc à me renseigner à ce sujet ?

C'était juste un exemple bidon. Ca fait partie de la famille des attaques dont le but est de faire afficher ou télécharger un fichier auquel on ne devrait pas avoir le droit. Quand le fichier est dans un dossier normalement interdit on peut parler de path traversal, mais c'est pas la seule chose à laquelle je pensais.

niuxe a écrit :

+1

Je me suis trompé de touche. En plus, je pensais à peu près comme vous deux (Quentin et kustolovic)

La solution du htaccess est simple à mettre en place.

Bonsoir;

Concernant le positionnement Google, j'aimerais avoir votre point de vue:

- On aimerait simplifier la situation
- Finalement, on aimerait toucher les francophones et les hispanophones où qu'ils soient

Activité: services par téléphone
Localisation: Espagne
Langues: français et espagnol
Pays visés: France, Belgique, Suisse, Espagne.
Serveur: en France
Domaines possédés:
monsite.be // monsite.ch // monsite.eu //
misitio.com (=>url traduite en espagnol) // misitio.es (=>url traduite en espagnol)

Vu, entre autre, le problème de duplication de contenu, et de langue de l'URL, voici le choix qui qui retient le plus notre attention :

monsite.eu => langue fr : sans localisation GWT, on touche tous les francophones où qu'ils soient ?
misitio.com => langue es : sans localisation GWT, on touche tous les hispanophones où qu'ils soient ?
(changement de langue: un click et l'usager part sur l'autre site)

Q : Le fait que le serveur se trouve en France, quelle influence cela a-t-il sur les .eu et .com
en matière de positionnement ?
Q : un .com en espagnol est-il moins efficace qu'un .es pour le positionnement en Espagne ?

Merci pour vos avis et commentaires

Je vais te faire remarquer un petit truc auquel tu n'as pas forcément pensé. Ce petit point peut devenir crucial si, un jour, tu cherches à passer des données client d'un site à l'autre.

Si tu t'orientes vers une structure du genre:
- FR: monsite.fr
- EN: monsite.com
- ES: monsite.es

Tu auras un petit problème au niveau des cookies. En effet, il est impossible d'aller stocker un cookie pour tes 3 sites de façon unique - il faudra que le visiteur visite les 3 sites l'un après l'autre afin d'avoir un cookie sur les 3. Chose très peu pratique.
Avec du en.monsite.fr et es.monsite.fr (avec HTTP 301 redirect des noms de domaine www.monsite.es et www.monsite.com), tu n'as pas ce pb.
Il y a moyen d'outrepasser le truc à coup de SSO, mais ça demande beaucoup de boulot.

Un autre point important: si tu veux un certificat SSL, il t'en faudra un pour chaque domaine, contre un seul dans le cas du monsite.com/fr/, ou un wildcard dans le cas des sous-domaines. Tu viens d'économiser un minimum de 60€ en choisissant l'une des 2 dernières options.

Après, si tu ne comptes pas utiliser de certificat SSL, et que tu n'en as rien à faire des cookies inter-site...

Concernant le SEO, que tu viens d'aborder.
- Le fait que le serveur se trouve quelque part n'a aucune influence directe sur les rankings Google. En fait, un résultat français apparait grâce à l'analyse de langue (méta language ou inferred language), pas grâce à la géoloc. T'imagines un peu si tous les gens sur EC2 en Irlande était flaggés comme des irlandais?
- L'URL n'a aucune influence directe. Par contre, si tous tes backlinks sont du Sri Lanka et pas d'Espagne, ça, ça aura une influence directe...

anima a écrit :

Concernant le SEO, que tu viens d'aborder.
- Le fait que le serveur se trouve quelque part n'a aucune influence directe sur les rankings Google. En fait, un résultat français apparait grâce à l'analyse de langue (méta language ou inferred language), pas grâce à la géoloc. T'imagines un peu si tous les gens sur EC2 en Irlande était flaggés comme des irlandais?
- L'URL n'a aucune influence directe. Par contre, si tous tes backlinks sont du Sri Lanka et pas d'Espagne, ça, ça aura une influence directe...

C'est assez faux

- le référencement sur les versions localisées de Google se font en premier lieu par l'extension localisée (si elle existe).
- Pour les extensions génériques ça se fait:
1) En l'indiquant soi-même à Google manuellement
2) Par géoloc du serveur et par analyse du contenu, mais pas de langue. Google ne peut pas se permettre de faire cette erreur de débutant qui consiste à croire que langue==pays.

Par contre, google analyse la langue du site pour répondre à des recherches par langue (ce que google fait automatiquement) et qui dépendent de la manière dont Google est configuré. Les sites qui ressortiront le mieux seront bien entendu ceux qui correspondent aux 2 critères: localisation + langue (ainsi que les autres critères bien entendu)

Maintenant on peut avoir un site par pays (ça a tout son sens) et ne pas offrir de traduction. Mais que chaque site soit dans une différente langue.

@anima Ok pour le certificat SSL, je n'y avait pas pensé, c'est bon a savoir pour l'avenir.
@ kustolovic Merci, je commençais à nouveau à ne plus rien comprendre !

Un des derniers points qu'il me reste à solutionner : 2 domaines , 2 sites et un serveur

J'ai lu hier quelque chose comme "ça ne sert à rien de dépenser de l'argent, tout peut être installé sur le même serveur"... très bien, mais :

A force de poser des questions, il m'est apparu que les "sites garés" ( parked domains) ne servent à rien dans mon cas. (Apparemment ils servent juste à se protéger du typo-squatting).

Alors il reste "domaines compagnons" ( Add-on domains), mais là, je ne pige toujours pas comment installer 2 noms de domaines différent et 2 sites différents sur le même serveur.

Le premier domaine et site www.monsite.eu en français , se trouvent dans public_html ( ou www ), qui lui-même est un dossier du home/surnom ( =>attribué par l'hébergeur)

Comment puis-je installer un www.monsite.com en espagnol , parallèlement ?
Si c'est possible, quelles sont les conséquences ? ( SEO ect ...)

Merci à tous !
Modifié par Tropiques (20 Dec 2013 - 15:39)

Alors les noms de domaines sont gérés par un serveur DNS, celui qu'on indique à son registrar.

En configurant ce serveur DNS on peut router ses adresses vers un serveur web (adresse IP). Il y a pleins d'options mais en gros on aura une config du genre:

monsite.com => 99.999.99.99
 www.monsite.com  => monsite.com
monsite.fr => 99.999.99.99
etc.

où 99.999.99.99 est l'ip du serveur.

Ensuite vient le serveur en lui-même
il faudra le configurer pour qu'il reçoive ces différentes adresses et les envoie vers un dossier. On peut soit gérer les sites en séparé (comme différents sites) soit comme un seul dossier qui analysera lui-même l'adresse appelante et répondra en fonction.

Là où ça se corse, c'est que sur un hébergement mutualisé, on se sert souvent du serveur DNS fourni par ses soins, et parfois l'hébergeur gère tout ça de manière totalement opaque et peu configurable. Parfois il donne accès à la gestion DNS directement.

Sur un serveur mutualisé, souvent 2 sites différents avec chacun leur nom de domaines signifie prendre 2 hébergements (c'est le principe du truc)

Avoir plusieurs sites sur un même serveur, certains hébergeurs mutualisés le permettent. Ils appelle ça domaine synonyme par exemple, et si ton but est de faire deux sites effectivement différents, il faut faire bien gaffe au fait que du point de vue du DNS ça se traduit souvent par du CNAME, une redirection en gros. Je ne sais pas ce que ça vaut au niveau du référencement mais je pense que c'est pas trop bon si le but était de faire deux sites vraiment différents.

Après il y a des hébergeurs qui proposent aussi 3 domaines avec des sous-dossier de stockage différents mais une ou les mêmes bases SQL. C'est plutôt vers ça qu'il faudrait opter je pense, si ton objectif est toujours d'avoir deux sites complètement indépendants. Par contre je crois que ce type d'offre se faire rare (j'en ai pas vu depuis un moment en tout cas) justement pour pouvoir raquer en te vendant autant de packs que de sites.

Petite note à part, si tu as 3 domaines ou plus, l'option serveur dédié peut devenir vachement intéressante. Niveau prix, OVH et dedibox sont extrêmement compétitifs. Pour ne pas trop s'embêter avec la technique si ce n'est pas ton but, je sais qu'il existe des distributions plus ou moins clés en main qui t'installent directement le système avec les services de base couramment utilisés (apache, php, MySQL, e-mail, anti-spam, FTP, DNS, etc. + un panel de gestion).