What Meta Tags Your Site Should be Using

Whenever you’re building a new site, you probably pay more attention to the HTML that’s in the <body> tag (i.e. the actual content) than what’s in the <head> tag – and that’s a good thing! If your page doesn’t have rich, valuable content – then it probably shouldn’t be there, but that doesn’t mean that you should put everything else on the backburner. There are tons of valuable tags you should be placing within the <head> tag that can really make your site more valuable, accessible, and help showcase it on social media platforms before people even click on links to your site. In this post, we’re going to go through which tags you should absolutely be placing in the <head> tag of your site if you want to get the maximum exposure and shareability possible. All of these are <meta> tags – with the exception of one – and the majority of them are related to how links to your site will render when shared on various social media platforms. I’m gonna group these into a few different categories:

  • General
  • Open Graph (i.e. Facebook)
  • Twitter

Ready? Let’s get to it!

tl;dr

Before we get into the explanations of all the meta tags, if you just want a quick example of what core meta tags I recommend every page should have (and the one’s we’ll be discussing), then here it is:

These meta tags are taken directly from this webpage. Now that we have that out of the way, I hope you’ll continue reading to see what these tags actually do and why they’re important!

General

These are gonna be the tags that every site should have, regardless of how you plan to use it.

Title

This one’s pretty easy to understand and it’s absolutely the most important tag you should place within your <head> tag. It’s also the only tag we’ll be talking about that’s not explicitly a <meta> tag – this one gets a tag all to itself. You probably already knew this, but the <title> tag sets the title of the page. This will be the title that you see in your browser tab, your bookmark menu, Google results, and practically anywhere that your site is shared. It’s a must to set this.

Viewport

Next to the title, the viewport meta tag is extremely important to have in your site because without it, your site won’t render properly on smaller screen sizes such as mobile phones and tablets. The viewport meta tag gives the browser instructions on how to control the page’s dimensions and scaling. On smaller devices by default, browsers will try to scale down the entire web page width to fit on your screen just like it would on a desktop monitor; you’ve probably seen this if you’ve viewed websites that haven’t been built recently, and you have to zoom in to actually read the content. With modern responsive websites, we don’t want that default behavior. We have the power to build websites that break down properly for smaller screen sizes, and in order to render these sites properly, we need the viewport tag.

Here’s an example of a basic viewport meta tag:

This tag sets the width of the page to the device-width (i.e. your viewport width), and the initial scale attribute sets the zoom level to 1, so that you’re not viewing a zoomed-in or zoomed-out version of the page.

Character Set

This meta tag sets the character set of your website. Browsers need to know which character set your site uses in order to render your content properly.  UTF-8 is the default character set for all HTML5 sites – but you still should be explicit about setting it because in HTML4, the default is ISO-8859-1. If you’re using HTML5 (which you should be), then this tag looks like this:

But if you’re stuck using earlier versions of HTML, then you’d use the http-equiv property to set the character set:

Description

The meta description tag sets a 255-character-max block of text that accurately describes the page you’re on. This tag has been the standard for services like Google, Facebook, Slack, and many others to pull in your page’s description for others to see, which makes it very important.

The limit that any service will pull from your meta description is typically 255 characters, so make sure you stay concise with it!

Open Graph

You probably read “Open Graph” above in the intro and may have thought, “what the heck is that?” Open Graph is a protocol that Facebook created that allows any web page links to become rich objects in a social graph. Whenever you paste a link in Facebook (along with many other services) and it automatically creates a clickable block with a title, description, and/or image from that site – it’s using these Open Graph meta tags to do that. Before I knew what was going on here, it always seemed like magic to me when this happened – but it’s all just from simple meta tags! The Open Graph protocol is abbreviated to og when used in HTML.

I’m gonna display a chunk of Open Graph meta tags here, and then we’ll talk about them.

You’ll notice that some of these tags seem redundant compared to the other tags we’ve added so far – and truth be told, I agree. But the Facebook Open Graph debugger throws warnings if you don’t have an og:title or og:description, so it’s best to include them for maximum accessibility.

og:title

This purpose of this meta tag is similar to the <title> tag that we discussed above, but strictly used when sharing a link to your web page. It wont be used for browser tabs, bookmarks, or Google search results like the actual <title> tag.

og:type

This describes what type of content you’re linking to. More often than not, this will be set to website, but as you see in the example, it doesn’t have to be. Check out the Open Graph docs for the various values that this meta tag can be set to.

og:url

This is the canonical URL that the Open Graph object will reference when shared, and it should 99% of the time be set to the URL of the page you’re linking. The only other value this should really be set to would be something like a home page, in case the current page (e.g. a 404 page, unauthorized page, etc.) really isn’t something you want shared.

og:image

Open Graph Object Example
Open Graph Object Example

This is probably the one that you’ve come across most often as a user, and the one that Open Graph really pioneered: an image meta tag. This tag links to an image file, and if it exists, it will display that image when shared on many social media platforms. While Open Graph was originally built by Facebook, several other services such as Slack, LinkedIn, Google+, etc. all use this to pull in an image when you share a web page.

Typically only JPEGs and PNGs are supported, but it’s really up to the platform you’re sharing it on. If they want to render gifs or svgs, then they can do that. When choosing an image size, there are a couple of recommendations.

1 – The image should be reasonably sized. Facebook and other services typically limit it to 8mB, but you really should never have an image that big on the web. My personal goal is to keep all images under 500kB.

2 – This is Facebook specifically, but they recommend an aspect ratio of 1.91 to 1, and further recommend images to be 600 x 315 or 1200 x 630 pixels. You can choose an image with any aspect ratio, but abiding by these guidelines will make sure that parts of your images don’t get cropped out.

og:description

Just like og:title is a doppelgänger to the title tag, og:description is similar to your meta description tag.

That covers the basic Open Graph meta tags, but as I mentioned earlier, there are more than just these if you want to get nitty-gritty with your site’s content. Let’s move on to our final category.

Twitter

Twitter has it’s own protocol suite for meta tags, and they involve rendering a “card” to your tweets which look just like Open Graph objects. In fact – Twitter will actually use Open Graph meta tags that you already have to help render your cards, which is nice so that you don’t have to duplicate any meta tag content. Here’s a base example of what meta tags you should use for Twitter:

There are more meta tags that Twitter supports such as image, title, description, etc., but the tags shown here are the important ones that are unique to Twitter. You can add those other meta tags – but as mentioned earlier, if they aren’t present, Twitter will go ahead and use the data provided by your Open Graph tags – which is what I prefer.

twitter:card

Twitter Summary Large Image Card Example
Summary Large Image Example

This is the most important twitter meta tag, and it’s required if you want to render a card at all. The various values can be one of ?summary?, ?summary_large_image?, ?app?, or ?player? – all of which you can read about here. The default value should be “summary”, unless you want to showcase a featured image, in which case you would use “summary_large_image.”

twitter:site

This meta tag describes the twitter username for the website used in the card footer, and is required if you want to track attributions to this username through Twitter Card Analytics.

twitter:creator

This meta tag describes the twitter username for the content creator/author.

That wraps it up for the must-have Twitter meta tags. As mentioned, there are plenty more, and if you’re interested you can read up on them here.

Final Thoughts

Did we cover every meta tag out there? Absolutely not – but we covered a lot of them that are pretty important. Some of the ones we missed out on include a whole suite of meta tags dedicated to deeplinking, where you can do things like tell an operating system (such as iOS, Android, or Windows Phone) to open up an app when you land on the webpage instead of rendering the webpage itself. You’ve probably seen this type of action happen when you click on a Twitter, Instagram, or Amazon link. We didn’t cover the author meta tag either, or different things you can do with the http-equiv attribute, or the keywords meta tag – and that last one’s for good reason; the keywords meta tag has become pretty unimportant, and if any SEO “gurus” try to tell you that it is important – then run. Run away, because that’s a bold-faced lie.

Now that you know the purpose of some of the various meta tags and how to use them, you can go update some of your projects to make them more shareable! I hope you enjoyed this post and learned a little bit more about how to power up the HTML in your web pages.

Core Functional Programming Concepts

If you’re a developer like me, then you probably grew up learning about Object-Oriented Programming and how that whole paradigm works. You may have messed with Java or C++ – or been lucky enough to use neat languages like Ruby, Python, or C# as your first true language – so chances are that you’re at least mildly comfortable with terms such as classes, objects, instance variables, static methods, etc. What you’re probably not as comfortable with are the core concepts behind this weird paradigm called functional programming – which is pretty drastically different from not only just object-oriented programming, but also procedural, prototypal, and a slough of other common paradigms out there.

Functional programming is becoming a pretty hot topic – and for very good reason. This paradigm is hardly new too; Haskell is potentially the most corely-functional language out there and has existed since 1990. Other languages such as Erlang, Scala, Clojure also fall into the functional category – and they all have a solid following. One of the major benefits of functional programming is the ability to write programs that run concurrently and that do it properly (check out my post on concurrency if you need a refresher on what that means) – meaning that common concerns such as deadlock, starvation, and thread-safety really aren’t an issue. Concurrency in procedural-based languages is a nightmare because state can change at any given moment. Objects have state that can change, practically any function can change any variable as long as they’re in lexical scope (or dynamic scope, for the few languages that use it) – it’s very powerful, but very bad at keeping tabs on state.

Functional programming touts many benefits – but the ability to take advantage of all of a CPU’s cores via concurrent behavior is what makes it really shine compared to the other popular programming languages today – so I want to go over some of the core concepts that power this language paradigm.


Foreword: All of these concepts are language-agnostic (in fact, many functional languages don’t even fully abide by them), but if you had to associate them with any one language, it would most likely fit best with Haskell, since Haskell most strictly abides by core functional concepts. The following 5 concepts are strictly theory-driven and help define the functional paradigm in the purest sense.

1. Functions are Pure

This is easily the foremost rule of functional programming. All functions are pure in the sense that they abide by two restrictions:

  1. A function called multiple times with the same arguments will always return the same value. Always.
  2. No side effects occur throughout the function’s execution.

The first rule is relatively simple to understand – if I call the function sum(2, 3) – then it should always return the same value every time. Areas where this breaks down in more procedural-coding is when you rely on state that the function doesn’t control, such as global variables or any sort of randomized activity. As soon as you throw in a rand() function call, or access a variable not defined in the function – then the function loses its purity, and that can’t happen in functional programming.

The second rule – no side effects – is a little bit more broad in nature. A side effect is basically a state change in something other than the function that’s currently executing. Modifying a variable defined outside the function, printing out to the console, raising an exception, and reading data from a file are all examples of side effects which prevent a function from being pure. At first, this might seem like a big constraint for functional programming – but think about it. If you know for sure that a function won’t modify any sort of state outside the function itself, then you have full confidence that you can call this function in any scenario. This opens so many doors for concurrent programming and multi-threaded applications.

2. Functions are First-Class and can be Higher-Order

This concept isn’t exclusive to functional programming (it’s used pretty heavily in Javascript, PHP, and among other languages too) – but it is a requirement of being functional. In fact – there’s a whole Wikipedia article over the concept of first-class functions. For a function to be first-class, you just have to be able to set it to a variable. That’s it. This allows you to handle the function as if it were a normal data type (such as an integer or string), and still be able to execute the function at some other point in runtime.

Higher-order functions build off of this concept of “functions as first-class citizens” and are defined as functions that either accept another function as an argument, or that return a function themselves. Common examples of higher-order functions are map functions which typically iterate over a list, modify the data based on a passed-in function, and return a new list, and filter functions, which accept a function specifying how elements of a list should be selected, and return a new list with the selections.

3. Variables are Immutable

This one’s pretty simple. In functional programming, you can’t modify a variable after it’s been initialized. You just can’t. You can create new variables just fine – but you can’t modify existing variables, and this really helps to maintain state throughout the runtime of a program. Once you create a variable and set its value, you can have full confidence knowing that the value of that variable will never change.

4. Functions have Referential Transparency

Referential transparency is a tricky definition to pinpoint, and if you ask 5 different developers, then you’re bound to get 5 different responses. The most accurate definition for referential transparency that I have come across (and that I agree with) is that if you can replace the value of a function call with its return value everywhere that it’s called and the state of the program stays the same, then the function is referentially transparent. This might seem obvious – but let me give you an example.

Let’s say we have a function in Java that just adds 3 and 5 together:

It’s pretty obvious that anywhere I call the addNumbers() function, I can easily replace that whole function call with the return value of 8 – so this function is referentially transparent. Here’s an example of one that’s not:

This is a void function, so it doesn’t return anything when called – so for the function to be referentially transparent, we should be able to replace the function call with nothing as well – but that obviously doesn’t work. The function changes the state of the console by printing out to it – so it’s not referentially transparent.

This is a tricky topic to get, but once you do, it’s a pretty powerful way to understand how functions really work.

5. Functional Programming is Based on Lambda Calculus

Functional programming is heavily rooted in a mathematical system called lambda calculus. I’m not a mathematician, and I certainly don’t pretend to be, so I won’t go into the nitty-gritty details about this field of math – but I do want to review the two core concepts of lambda calculus that really shaped the structure of how functional programming works:

  1. In lambda calculus, all functions can be written anonymously without a name – because the only portion of a function header that affects its execution is the list of arguments. In case you ever wondered, this is where lambda (or anonymous) functions get their name in modern-day programming – because of lambda calculus. *Brain explosion*.
  2. When invoked, all functions will go through a process called currying. What this means is that when a function with multiple arguments is called, it will execute the function once but it will only set one variable in the parameter list. At the end, a new function is returned with 1 less argument – the one that was just applied – and this new function is immediately invoked. This happens recursively until the function has been fully applied, and then a final result is returned. Because functions are pure in functional programming – this works. Otherwise, if state changes were a concern, currying could produce unsafe results.

As I mentioned earlier, there’s much more to lambda calculus than just this – but I wanted to review where some of the core concepts in functional programming came from. At the very least, you can bring up the phrase lambda calculus when talking about functional programming, and everyone else will think you’re really smart.

Final Thoughts

Functional programming involves a significantly different train of thought than what you’re probably used to – but it’s really powerful, and I personally think this topic is going to come up again and again with CPUs these days offering more cores to handle processes instead of just using one or two beefed up cores per unit. While I mentioned Haskell as being one of the more pure functional languages out there – there are a handful of other popular languages too that are classified as functional: Erlang, Clojure, Scala, and Elixir are just a few of them, and I highly encourage you to check one (or more) of them out. Thanks for sticking with me this long, and I hope you learned something!