Rendre un portfolio Next.js visible sur Google : le SEO qui compte vraiment

Le problème : bien référencé ne veut pas dire bien présenté

Quand on tape mon nom sur Google, mon portfolio sort en première position. Le référencement fonctionne. Mais un bon classement ne garantit pas un bon rendu : l'icône affichée à côté du lien, le nom du site, la description — tout cela se joue sur des signaux techniques précis que Google lit dans votre code.

Cet article détaille les réglages qui font la différence entre un résultat générique et un résultat qui inspire confiance.

Le favicon : une contrainte que presque personne ne respecte

Google affiche une icône à gauche de chaque résultat. Pour qu'elle soit la vôtre et pas un fallback générique, trois conditions :

• Le favicon doit être servi à une URL stable et déclaré via <link rel="icon">.
• Sa taille doit être un multiple de 48px (48, 96, 144…). Un 64×64, pourtant courant, est tout simplement ignoré par Google.
• Il doit rester lisible à très petite taille : un monogramme ou un symbole, jamais un logo détaillé.

En Next.js, un simple fichier app/icon.tsx génère le favicon et injecte automatiquement la balise <link>. Le piège se cache dans la taille exportée.

Un favicon parfait mais en 64×64 ne s'affichera jamais dans les résultats Google. Le détail qui coûte des semaines de doute.

Le « nom de site » : reprendre la main sur ce que Google affiche

Par défaut, Google affiche souvent le domaine (monsite.com) à la place du vrai nom. Pour lui imposer un nom propre, il faut aligner trois signaux qui doivent être strictement identiques :

• Le champ name des données structurées WebSite (JSON-LD).
• La balise og:site_name (Open Graph).
• La meta application-name.

Si ces trois valeurs divergent — ne serait-ce que « Portfolio Jean » d'un côté et « Jean — Portfolio » de l'autre — Google abandonne et retombe sur le domaine. La cohérence est la seule règle.

Les données structurées : expliquer qui vous êtes

Le JSON-LD Person est ce qui permet à Google de comprendre que le site parle d'un individu précis, avec un métier, une localisation et des profils sociaux. Les champs qui pèsent le plus :

• name, jobTitle, description — l'identité de base.
• sameAs — la liste de vos profils (GitHub, LinkedIn). C'est ce qui relie votre site à votre présence en ligne et alimente le Knowledge Panel.
• image — une photo, utile pour les résultats enrichis.

Relier chaque entité par un identifiant @id (#person, #website) évite les doublons et donne à Google un graphe propre plutôt qu'une collection de fiches isolées.

Le sitemap multilingue : ne pas se faire dévorer par les hreflang

Un site en plusieurs langues doit dire à Google quelle version montrer à qui. Sans cela, les différentes langues se cannibalisent dans l'index. La règle : chaque URL déclare toutes ses variantes linguistiques via alternates.languages, plus un x-default.

Next.js génère un sitemap.ts natif où chaque entrée porte ses hreflang. C'est plus fiable que les plugins tiers, qui ratent souvent les routes dynamiques du type [locale].

Ce qui compte vraiment, dans l'ordre

Si je devais prioriser pour un nouveau projet :

1. Google Search Console — sans lui, vous êtes aveugle. Soumettez le sitemap, demandez l'indexation.
2. Cohérence des signaux d'identité — favicon conforme, nom de site aligné, JSON-LD propre.
3. Du contenu réel — un site d'une seule page plafonne vite. Des articles techniques comme celui-ci vous font exister sur de vraies requêtes.
4. Les Core Web Vitals — un site rapide est un site mieux classé. Mesurez, puis optimisez.

Le SEO technique n'est pas de la magie : c'est une série de signaux clairs, envoyés proprement, puis laissés au temps que Google met à re-explorer. La patience fait le reste.