Hugo and the General Data Protection Regulation (GDPR)

Hi everybody!

Hugo offers GDPR friendly settings. Although I really appreciate the effort, I think they may be insufficient.

The GDPR friendly settings will instruct the platforms to NOT TRACK, through the DNT-directive (do not track). However, GDPR is not about tracking, but about leaking Personal Identifiable Information (PII) to third parties. Even an IP address is considered to be PII. Your data (IP address and meta data) may end up in logs of other hosting providers or in the US governments database through systems like the PRISM project

A German court recently fined a website owner for loading Google Fonts. AFAIK you are only allowed to create LINKS TO other webpages, given that you clearly mark what website your are linking to. The website visitor is considered to give explicit consent by clicking the link. Any other form of third party content is prohibited, unless you have explicit consent (through a cookie banner for example).

Should we change this page in the Docs? Should we leave out the ‘GDPR’ claim and change the title of the page to ‘Privacy settings’? This would prevent the Hugo docs from giving (potentially) wrong legal advice.

I would love to hear your opinion!


I agree that it would be best to at most mention GDPR in a footnote on that page. Mentioning GDPR in the title can easily give people the wrong impression. If one read the “Note that:” part all is explained but better to be clear from the start.


I like that idea!

I agree with you.

It would be better to avoid misinformation about the GDPR, where the Hugo official website should contain technical information only without falling into possible legal mistakes.

Indeed, the title of the GDPR is “the protection of natural persons concerning the processing of personal data and on the free movement of such data”. Thus, the protection is related to natural persons and not data.

The common mistake is to consider that it falls under the GDPR for data protection. Instead, the protection is related to natural persons and their personal information, avoiding the unlawful processing of their personal data.

No doubt regarding the IP as personal information like others one technical.

I agree this is important to help people with such a délicate and complicated matters.

For exemple see my comment for stock GA partial.

I know almost nothing about GPDR compliance. It seems to be a moving target, requiring maintenance by someone with some smarts in this area.

Which of Hugo’s internal templates (e.g., _internal/*, shortcodes) have features that require compliance?

What’s the downside of deprecating these, removing them from the documentation? In short, can we make this someone else’s problem?

1 Like

Anything that hits a third party server, without prior disclosure, and opt-out ability, afaik.

Hence the recently raised issue of using Google fonts, if you don’t provide a user the ability to opt-out of your fonts you are exposing that visitors ip address to Google, without their consent.

So I think this is the list that hits a third party server.


  • disqus.html
  • google_analytics_async.html
  • google_analytics.html
  • google_news.html (already deprecated)


  • gist.html
  • instagram_simple.html
  • instagram.html
  • twitter_simple.html
  • twitter.html
  • vimeo_simple.html
  • vimeo.html
  • youtube.html

Some old comments from others on the subject:

So I think this is the list that hits a third party server.

Those services are no problem/actually quite useful in non-European countries. They are also allowed in the EU when you have explicit consent. I do not think that these services/shortcodes are the point/problem.

However, providing privacy settings that claim GDPR compliancy seems like legal advice to me. You could make a footnote, as proposed. This could somehow link these privacy settings vaguely to the GDPR saying something like “These privacy settings enhance the privacy of the visitor and can be useful in the process of making a website GDPR compliant.” I would refrain from any other claim or further mention of the GDPR.

My 2 cents…

1 Like

Yes, but I think we can discount those that hit a 3rd party server at render time, as that does not expose the users ppi.

Without checking I’d say that opengraph and twitter simple, possibly gist?, should be ok, they’re not ‘info-leaky’ afaik.

Update: I was wrong about the GH gist. From my test page of internal templates :expressionless:

Yeah, opengraph was a copy/paste error on my part. I’ll edit the list.

The gist shortcode includes:

<script type="application/javascript" src=" ...
1 Like

True… but not the point IMO. Every developer in the EU knows (or should know) what is allowed. It is not the task of Hugo to produce GDPR compliant websites. You can build ANY website with Hugo: a GDPR compliant and a wildly non-compliant one. The only thing Hugo should REFRAIN from is advice you on how to achieve that. That is not the task of Hugo, it is country-specific and it is most likely incorrect… thus risky.

1 Like

Yes, user opt-in. This is important.

A good point. It should be made clear what the potential effects of using certain inbuilt templates might be, not everyone is a professional web dev and/or lawyer.

I have to disagree here. I don’t see any inherent risks to privacy-first, secure by default architecture. No-one will ever be prosecuted for not giving away ppi to 3rd parties without consent.

Should it? I think we cannot and won’t fix that for them. Wix, Wordpress and Squarespace are neither solving that for their customers (just to name a few website builders). GDPR is very complex. Hugo should draw the line at privacy settings and SHOULD leave the rest to professionals and lawyers.

:slight_smile: true! I love your enthusiasm.

I meant that the current privacy friendly options at the current ‘Hugo and GDPR’ page might be not GDPR compliant, thus risky. I agree that privacy by design is a good approach, but it is far from mainstream and only relevant in the EU (and California?)… Therefore, removing all third party requests might be one bridge to far for now.

To be clear, I am not advocating removal of internal partials and shortcodes. I’m just putting the idea out there for discussion.

It seems like the GPDR concerns can be addressed with documentation as @jhvanderschee suggests.

Unrelated to GPDR, we also have this:

Some of these are things that are broken, and some are improvements. Making them someone else’s problem is attractive, but again, I am not advocating their removal.

How another SSG handles it:


Not in France, Austria, …
related to where the data are stored.

But I agree with @jmooring, this is not Hugo job to be RGPD or whatever compliant.

But it is Hugo responsability to warn the user when they use a template/shotcode who can be problematic or illegal.

And i agree with his list of template/shortcode concern.

1 Like

Harry I took care of it.