15 août 2022

Les hébergements WordPress ne sont pas tous les mêmes.

Voyons le cas de ce journal qui a décidé de changer de fournisseur en basculant sur un hébergement défaillant.

Comme nous l'avons écrit plus tôt dans cet article citant un cas d'un ancien client, tous les hébergements ne sont pas identiques.

Il arrive très rarement de voir partir des clients, cependant il arrive, quoique peu fréquemment, que des clients ignorants (au sens le plus étymologique du terme, c'est-à-dire qu'ils ignorent, c'est-à-dire qu'ils ne savent pas) soient recommandés par des personnes (encore plus ignorantes) qui, jouissant d'une pleine confiance, recommander des solutions sur la base de l'instinct ou de la bonne impression d'un vendeur en poste, sans se soucier du tout de la validité de la solution proposée et de la validité de l'entreprise sur laquelle ils s'appuieront.

Tant que ça va et que vous faites le bon choix, être un idiot n'est pas grave, en fait cela peut être confondu avec une vertu. Mais lorsque le mauvais choix est fait, l'idiotie a un coût pour beaucoup de gens que l'idiot en tant que tel n'a même pas la connaissance des faits.

Bien que cela ne soit pas un problème pour un site vitrine local, il pourrait être délétère et décréter la faillite entrepreneuriale d'un journal qui vit selon ce modèle économique désormais habituel basé sur des revenus publicitaires directement proportionnels au nombre de visites.

Un concept très clair doit toujours être rappelé, aujourd'hui être en ligne signifie en fait rivaliser avec d'autres réalités (dans ce cas, testé en ligne) concernant les contenus et la qualité de ceux-ci, ainsi que des facteurs déterminants tels que l'expérience utilisateur qui devient aujourd'hui plus que jamais un facteur de classement et non plus une simple métrique de vanité fin en soi.

L'expérience utilisateur est en cours d'évaluation par Google à travers les données Vitaux Web de base Type CRUX et pas seulement Labs.

En bref, cela signifie que chaque navigateur basé sur le moteur Chromium, ou le moteur développé par Google sur lequel Chrome est basé, enverra des données à Google pour chaque page consultée dans lequel seront indiqués les paramètres techniques appelés Vitaux Web de base, et parmi ceux-ci également le temps de chargement de la page.

Il va sans dire que si un site est lent, les visiteurs utilisant Chrome donneront ces notes à Google et Google comprendra que le site est lent.

À ce stade, Google devra décider s'il continue à afficher ce contenu et ce site, ou s'il décide de préférer et de se positionner en premier, un autre site concurrent qui rapporte les mêmes nouvelles mais qui est beaucoup plus rapide. Evidemment la réponse est évidente et la question rhétorique, car Google a intérêt à proposer des expériences utilisateur satisfaisantes et donc plus le site est lent, plus il est probable (disons sûr) que le journal perde du trafic de façon importante et donc aussi des visites , moins d'impressions de bannières, moins de rémunération des circuits publicitaires et moins de monétisation.

Un modèle commercial non durable est celui de l'édition en ligne en dessous du seuil de rentabilité.

Il faut partir d'une notion fondamentale dans le monde de l'édition en ligne, écrire un contenu a un coût, une rédaction a un coût (c'est pourquoi beaucoup préfèrent déléguer la rémunération à une seule pièce), et écrire plus d'articles par jour équivaut à acheter plus de dossiers par jour jeu de bingo ou de tombola si vous préférez.

Quiconque a affaire à de nombreux journaux et blogs en ligne (nous en gérons une centaine environ), sait que tous les articles ne génèrent pas le même trafic, pour plusieurs facteurs :

  1. Il y a des sites qui traitent mieux le sujet et sont récompensés sur les SERP
  2. Il y a des sites qui deviennent viraux en premier parce qu'ils sont relancés par des personnalités telles qu'un politicien (et cela donne à Google le contrôle pour le garder viral)
  3. Il y a des sites qui arrivent avant nous, donc pendant quelques heures, un petit blog d'un blogueur privé qui écrit un article par semaine, devancera les journaux d'importance nationale.
  4. Il y a des sujets qui n'ont tout simplement pas d'intérêt et donc peut-être qu'on se positionne en premier pendant des journées entières mais on fait 1000 visites par jour.

De là, il est facile de comprendre qu'un magazine en ligne doit publier de nombreux articles pour trouver ces deux ou trois qui sont forts et permettent non seulement de compenser les coûts des autres articles qui n'ont pas eu suffisamment de lectures pour atteindre le seuil de rentabilité, mais de produire un bénéfice de nature à couvrir les frais de subsistance de l'activité entrepreneuriale ainsi qu'à produire un bénéfice plus ou moins visible pour l'éditeur qui reste en fait un entrepreneur.

Évidemment, il faut aussi évaluer la rémunération et le business model à développer, chacun avec ses avantages et ses inconvénients, et bien souvent un mix des trois principaux.

  1. Rémunération via les circuits publicitaires Google AdSense : Normalement il a un RPM (Revenu pour mille) bas, mais il n'impacte pas lourdement l'expérience utilisateur, se limitant au chargement de bannières publicitaires display et permet d'être assez calme selon la logique peu mais bon et pour longtemps .
  2. Rémunération via des circuits publicitaires alternatifs à Google AdSense : Ils ont tendance à payer plus et parfois beaucoup plus que Google Adsense, mais dans certains cas, certains concessionnaires ont tendance à être très intrusifs, risquant de donner une mauvaise expérience utilisateur et de mettre gravement en danger la durabilité à long terme.
  3. La vente de Guest post : il s'agit d'une activité plutôt rentable basée sur l'autorité de votre site dans laquelle l'écriture d'une pièce peut être vendue 50 - 100 euros et consiste en fait à créer un publireportage avec un lien de sortie vers le site du client qui paie pour obtenir un lien depuis le site puis "push" le classement. Il va sans dire qu'un journal ne pourra jamais vivre de posts invités, sinon en les dosant de manière très parcimonieuse au sein de la ligne éditoriale. De plus, Google n'aime pas du tout qu'un site commence à avoir beaucoup de liens sortants, surtout s'ils se suivent. Il n'est pas stupide et comprend facilement la raison et la cause des liens sortants vers des sites qui viennent de naître et/ou avec un très faible pagerank.
  4. Vente directe de bannières sans intermédiaires : l'exemple classique dans lequel le journal qui parle de la Sardaigne décide de vendre des espaces publicitaires à la société de location de voitures aux touristes visitant la Sardaigne. Dans ce cas, l'enseigne est vendue dans ce qui est une négociation spécifique et qui peut significativement affecter et casser la logique du marché. Supposons que cette bannière en position Top Header pendant la saison estivale vaut 1000 euros par mois, par rapport à la saison hivernale qui en vaut 200.

Peu importe comment vous voulez y penser et mélanger les nombreuses options ci-dessus, l'objectif ne change pas, avoir une différence entre le chiffre d'affaires et les coûts qui génère un profit. Tant que le solde est fortement positif, positif ou légèrement négatif (pour une courte période), l'éditeur peut pousser la ligne éditoriale et sa rédaction et rédiger de nombreux articles dont certains seront négatifs, certains seront à l'équilibre, d'autres sera en fort profit.

Que se passe-t-il lorsque votre site est lent et que Google vous pénalise ou ne vous récompense pas ?

Lorsque Google vous pénalise ou ne vous récompense pas, peut-être en ne plaçant pas vos articles dans Google Actualités, et en ne vous faisant pas apparaître sur Discovery, ou peut-être en vous faisant apparaître sur les deux, mais moins fréquemment et pour moins d'articles, il arrive que le le journal commencera à faire moins de visites. . Disons par exemple, un tiers de moins. Ce tiers de moins n'est pas rémunéré par Google (ni par le circuit publicitaire alternatif évoqué plus haut) et donc l'éditeur décide plutôt de publier 90 articles par jour, d'en publier 60 pour limiter les coûts et avoir toujours un bénéfice par rapport aux coûts.

Il se trouve alors ce faisant, que dans ces 30 articles manquants, peut-être l'article sur la candidature de l'ancien conseiller maire ou la pièce qui parle des vers trouvés dans une marque de pâtes bien connue qui aurait été la tendance du moment et aurait produit à lui seul peut-être 250 1000 visites qui, au coût "standard" de deux euros pour 500 impressions, auraient rapporté un montant de XNUMX euros.

Si l'on considère que le prix moyen d'un article en ligne est de 5 euros, cela signifie que ces 500 euros nous auraient donné l'opportunité d'écrire 10 autres articles, dont peut-être 2 autres seraient devenus viraux, nous rapportant encore un demi-million de visites. , et nous permettant d'avoir suffisamment de revenus pour mettre de côté une partie des revenus et réinvestir le reste pour la rédaction de nouveaux articles ou d'autres activités satellites telles que le positionnement plus efficace des bannières, l'embauche de serveurs plus rapides, le conseil SEO, les experts PageSpeed ​​​​et les situations qui si elles sont bien structurées, elles amènent l'entreprise à croître en termes de trafic, de valeur et de RPM.

Bref, si vous n'avez pas de visibilité, et que votre site ne fait pas des centaines de milliers de visites par jour, vous n'aurez pas les moyens d'entretenir une rédaction et de rémunérer les chroniqueurs, au point que licenciement sur licenciement, vous sera laissé seul à écrire des articles sur testé avant de se rendre compte qu'en fait le jeu n'en vaut pas la chandelle et vous avez maintenant arrêté ce "mouvement perpétuel" fait d'articles, de visites, de monétisation, d'articles, de visites, de monétisation, d'articles, de visites de monétisation, dans un lent crescendo continu.

Le cas précis évidemment censuré.

Pour des raisons évidentes que nous ne pouvons pas nommer et mentionner car il y a toujours une approche professionnelle même avec les situations les plus démangeaisons que nous aimerions vraiment vous dire dans tous les aspects, cependant il suffit de penser qu'après deux ans et 3 mois d'hébergement WordPress service offert à un journaliste de journal, l'éditeur inspiré par une entreprise dirigée personnellement qui prétend faire de la publicité (dans le portefeuille de clients il n'y a pas de noms éminents ou d'études de cas admirables) en ligne et au-delà, décide de changer de fournisseur d'hébergement.

Il y a. Il est normal, licite et correct d'essayer de faire mieux ce qui jusqu'alors était très bien fait, considérant toutefois, sans trop de pudeur, mais non sans trop de sensationnalisme, que toutes les spécifications techniques d'une pile logicielle côté serveur, encore permettez-nous de servir des clients comme celui-ci que vous voyez avec ces chiffres et ce calibre, Trafic AMP plus trafic normal, 85 millions de pages vues par mois.

Il est donc facile de supposer et de comprendre que le nouveau fournisseur d'hébergement WordPress sera certainement meilleur que le nôtre et fera certainement mieux que nous.

Nous avons donc attendu que le site soit migré pour d'abord dresser des bilans, selon l'optique « mesurer pour décider », et ensuite aussi tirer des conclusions.

Nous avons donc attendu que le commutateur DNS s'aperçoive immédiatement en le parcourant par des utilisateurs normaux avec le navigateur comme le ferait n'importe quel visiteur que le site était extrêmement lent. Un temps d'attente de plusieurs secondes avant d'envoyer les ressources et une expérience utilisateur agaçante et énervante dès le départ.

La même expérience qui devenait impossible avec les temps d'attente bibliques si elle se faisait en cliquant sur un lien de Facebook.

Nous avons donc évalué que le site était trivialement chargé sur un serveur avec Plesk et qui ne supportait pas beaucoup de fonctionnalités techniques et technologiques qui distinguent notre service d'hébergement WordPress axé sur la performance.

Nous avons donc évalué la vitesse de navigation avec Pingdom et comparé dans une analyse différentielle honnête aux données en notre possession mesurées avec Pingdom dont nous rapportons ci-dessous les captures d'écran évidemment censurées.

 

Site migré Comparaison Pingdom avant après

Comment pouvons-nous voir le site qui s'ouvrait auparavant en 1,02 seconde prend désormais 7,25 secondes. Par souci d'exactitude et de transparence, bien qu'une seule capture d'écran soit signalée, il faut dire que si notre hébergeur a ouvert le site sur plusieurs tests dans une plage de temps allant de 950 ms à 1,3 seconde, le nouveau fournisseur avait une valeur minimale de 3,5 , 13 secondes jusqu'à une valeur maximale de 4, avec une fréquence moyenne d'au moins XNUMX secondes.

Disons aussi qu'il est correct et pacifique de dire sans considérer les pires cas, que au mieux le nouveau fournisseur est QUATRE FOIS PLUS LENT que nous.

Il y a ceux qui prétendent qu'une page d'accueil, ou plutôt une page web qui pèse 5,5 Mo, est un poids absolument insuffisant pour un site web et on ne peut s'empêcher d'être d'accord avec ce constat, cependant il est bon de s'attarder sur le fait qu'un quel que soit le poids qui n'a pas changé dans la migration, restant entre 5.6 et 5.7 mégaoctets de poids total, le site s'est bien chargé auparavant SEPT FOIS plus vite.

On ne parle pas de 10% ou 20% de plus, des valeurs qui justifient déjà la transition vers un fournisseur meilleur et plus compétent, mais on parle d'une aggravation de 700%.

Nous avons parlé au contact technique pour soulever le problème.

On a parlé par téléphone avec le contact technique (en plus en regardant dans la correspondance Outlook, c'était déjà un de nos contacts depuis 2020) "le gars qui s'occupe de la publicité" pour parler d'autres opportunités de collaboration et on a fini par parler du mauvais boulot cela a été fait en termes de rapidité de passage au nouveau fournisseur, avec un TTFB très élevé et une heure d'ouverture du site qui même à 0h23 du mois d'août (au cours de laquelle le serveur doit être déchargé sans que personne ne soit connecté) il renvoie un SHAMEY TTFB de 4,2 secondes.

Une valeur vraiment embarrassante si on la mesure avec celle d'un autre de nos clients "Ilcorrieredellacitta.com" qui monte exactement le même thème et a un TTFB de 0,169 seconde soit 24,8 fois moins, c'est 24,8 fois MIEUX.

[root @ mail ~] # time curl -I https://www.laCENSURATO.it HTTP / 1.1 200 OK Date : dim. 14 août 2022 22:22:58 GMT Content-Type : text / html; jeu de caractères = connexion UTF-8 : lien persistant : ; rel = raccourci varie : Accept-Encoding x-cache-status : MISS x-powered-by : PleskLin CF-Cache-Status : DYNAMIC Expect-CT : max-age = 604800, report-uri = "https : // report- uri.cloudflare.com/cdn-cgi/beacon/expect-ct "Report-To: {" endpoints ": [{" url ":" https: \ / \ / a.nel.cloudflare.com \ / report \ / v3?s=523ix60ANRh931Z7AmsEGyyptL%2BkA2kmPbqgbjFRK%2BbJymfkn8EPXn 9kdJESMDxx1xcNO%2Br1VXG4TBP45rPN6Ti1zMwPuP01yMnAL9a%2FcRGLwXoDFridRIT%2BO8Go0347CjaxAuqc0tpAXCc%3D"}],"group":"cf-nel","max_age":604800} NEL: {"success_fraction":0,"report_to" : "cf-nel", "max_age": 604800} Serveur : cloudflare CF-RAY : 73ad17865d3ec2ac-VIE alt-svc : h3 = " : 443" ; mais = 86400, h3-29 = " : 443" ; ma = 86400 réel 0m4.269s utilisateur 0m0.037s système 0m0.025s
[root @ mail ~] # time curl -I https://www.ilcorrieredellacitta.com HTTP / 1.1 200 OK Serveur : nginx Date : Dim 14 août 2022 22:25:09 GMT Content-Type : text / html; jeu de caractères = Connexion UTF-8 : keep-alive Vary : Accept-Encoding Link : ; rel = "https://api.w.org/" Lien : ; rel = "alternatif" ; type="application/json" Lien : ; rel = shortlink Dernière modification : dim. 2 août 5 14:2022:22 GMT X-Cacheable : OUI X-Varnish : 02 14 Âge : 980407952 Via : 980393209 vernis X-Server : Managedserver.it Hosting X-Cache : HIT X -Hosting-By: managedserver.it - ​​Hébergement géré de performance real 1375m1.1s user 0m0.169s sys 0m0.040s

Le fait est que l'ayant contacté en mentionnant le problème et invité à vérifier les valeurs de vitesse, il a préféré nous liquider en disant que il avait fallu 40 jours pour planifier la migration, (j'insiste QUARANTE JOURS), et était pressé de partir en vacances et ne voulait pas refaire la migration pour revenir au serveur où il se trouvait avant.

A la communication des problèmes SEO à venir qui seraient survenus peu de temps après pour les raisons énumérées ci-dessus relatives à Vitaux Web de base et la rapidité du site, nous invite à adresser nos "réclamations" et indications à l'éditeur. La réponse est évidemment assez évidente et c'est celle que l'on ne peut pas se tourner vers l'éditeur car il est ignorant au sens étymologique du terme, c'est-à-dire un individu incapable de faire face à la virtuosité sur un plan technique tel que TTFB, Early Data, TCP BBR et divers acronymes qui sont complexes à argumenter même entre ingénieurs système compétents.

Ce personnage qui continue dans l'appel téléphonique se définissant comme vendeur et non comme technicien, pense bien afin de nous discréditer qu'il convient de contacter l'éditeur pour lui communiquer que nous lui avons donné l'ignorant le décontextualisant du contexte et le laissant entendre comme une insulte gratuite, plutôt qu'une évaluation objective pacifique des compétences de le même.

L'éditeur a pris connaissance de ce qui lui a été communiqué comme une insulte, communique à des tiers en commun que notre société l'insulte, et bien sûr le revendeur de service appelle pour savoir ce qu'il se passait depuis que l'éditeur lui a communiqué que nous l'insultions alors en fait, aucun membre de notre société n'a parlé du tout à l'éditeur, mais seulement à son contact de confiance (le bricoleur publicitaire qui veut aussi comprendre la technologie).

Évidemment nous contactons l'éditeur, tout d'abord pour nous excuser du malentendu et évidemment pour expliquer le contexte faisant référence à l'inutilité de parler de technicité avec un non-technique comme nous l'avons fait plus haut.

Nous trouvons une personne préjugée, agaçante qui en fait nous liquide en 10 secondes au téléphone, ne nous laissant même pas 1 minute pour initier un discours harmonieux et apaisé qui aurait fait la lumière sur l'histoire et l'avait prévenu des effets néfastes et imminents de ce choix méchant, à savoir celui de choisir un fournisseur qui a transformé un site rapide en un site absolument inadéquat pour gérer un journal en ligne.

Évidemment, je comprends les problèmes de l'éditeur, ainsi que l'histoire singulière qui professionnellement parlant de 2005 à aujourd'hui n'a pas d'égal, on se demande si l'éditeur ou sa personne de confiance a la compétence pour comprendre au moins spannométriquement quelles peuvent être les conséquences que devrait être évident même pour toute personne non technique, lorsque vous commencez par "le site est maintenant SEPT fois plus lent".

À cet égard nous avons interrogé des personnalités professionnelles qui peuplent des groupes Facebook tels que Facts of SeoZoom, Web Developers Italia et autres, demandant, en publiant la capture d'écran du test pingdom ci-dessus dans l'analyse différentielle avant et après, quelles pourraient être les conséquences de cette lenteur. Quelqu'un a également voulu tenter de deviner quelles pourraient en être les causes, et cette approche superpartes sert une fois de plus à comprendre et démontrer combien d'entreprises improvisées opèrent encore là-bas sans avoir à cœur l'entreprise du client, et la rédaction qui sera bientôt licenciée car le journal ne monétisera plus suffisamment.

 

Il était évidemment facile de comprendre quelles étaient les réponses données par les professionnels, pour un professionnel, mais c'est bien encore une fois d'avoir et de montrer des confirmations superpartes pour montrer qu'on n'invente rien on les approche par des mensonges comme le font certains hébergeurs qui le font ne pas avoir la décence et l'éthique morale de ne pas prendre un client s'il ne parvient pas à ajouter de la valeur et à améliorer une situation de départ.

Il existe (malheureusement) des sociétés d'hébergement qui n'ont aucun respect pour le client et n'ont aucun problème à faire échouer des entreprises entières afin de vendre un serveur de plus.

Le plus déconcertant de toute l'histoire dans ce triptyque d'ignorants est que personne ne semble se soucier du sort du journal, ni de l'éditeur, un personnage hautain pour comprendre que peut-être ils ne font pas leur intérêt, ni le personnage de confiance (alias publicité commerciale) qui semble n'avoir qu'une hâte exclusive à partir en vacances et ne se soucie pas des dommages causés auxquels elle ne remédie pas, ni du nouvel hébergeur qui se désintéresse bien de restaurer ou du moins d'améliorer ces valeurs ci-dessus qui suggèrent une insouciance et une incompétence absolue.

Je suis juste désolé pour la rédaction, les chroniqueurs et tous ceux qui subiront les conséquences de cette bande d'improvisés qui jouent à l'entrepreneur sans aucune connaissance des faits et rejettent même les suggestions et les avertissements sur ce qui se passera si le situation actuelle persiste.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page