meta-tags: Rails helpers for titles, canonical URLs and Open Graph tags
Search Engine Optimization (SEO) for Ruby on Rails applications.
At a glance
- What is it?
- meta-tags is an MIT-licensed Ruby gem that renders HTML head metadata from Rails controllers, views and models. It covers titles, descriptions, canonical links, robots directives, Open Graph and X cards, but it deliberately stops short of JSON-LD, sitemaps and robots.txt.
- Who is it for?
- Adopt meta-tags if you run Rails 6.1 or newer and want head metadata built from controllers, views and model objects rather than hand-written ERB. Skip it if you need JSON-LD structured data, sitemaps or robots.txt, since the README states it generates none of those.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Ruby, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What meta-tags solves for Rails applications
Rails gives you no built-in way to assemble the contents of the head element. Most teams end up with a layout full of conditionals, or with each view setting instance variables that the layout reads. meta-tags replaces that with a single helper call in the layout and per-page declarations in views or controllers.
The gem is aimed at Rails developers who care about the metadata layer of search engine optimization: page titles, meta descriptions, canonical links, robots directives, and the tags that social platforms read when a URL is shared. The README is explicit that this is the whole scope. It states that MetaTags does not generate structured data or JSON-LD, robots.txt, sitemaps, internal links, or page content. If you were hoping for a one-gem SEO solution, this is not it, and the maintainers say so up front.
That narrow scope is the interesting design choice. A title and a canonical URL are things a Rails app already knows at request time, so generating them in the view layer is natural. A sitemap is a batch artifact, and JSON-LD usually describes an entity with a schema that has nothing to do with the HTML head. Keeping those out avoids a helper that tries to be a content management system.
How display_meta_tags and set_meta_tags divide the work
The mechanism is a two-part contract. In the layout you call display_meta_tags, which renders the tags into the head. In views or controllers you call set_meta_tags, which accepts the same arguments but renders nothing where it is called. The README marks this as important: display_meta_tags must appear in the layout, and set_meta_tags is what you use everywhere else.
A title passed through the title helper is also returned, so the same string can be printed as the visible h1. The README shows a two-argument form, title "Member Login", "Here you can login to the site:", which sets the metadata title while displaying different text on the page. That is a small detail with real consequences: it removes the usual duplication where a page heading and a document title drift apart over time.
Data can enter from three directions. Controllers can set @page_title and @page_description. Views can call individual helpers such as title, description, nofollow, noindex and refresh. Any object that implements to_meta_tags and returns a Hash can be passed straight to set_meta_tags, which lets a model own its own metadata. The README gives a Document class whose to_meta_tags returns title and summary keys.
Rendering defaults are configurable. Some tags must be emitted with the property attribute rather than name, and the README says the pre-configured list covers all Facebook Open Graph object types, with room to add your own. The allowed options table lists site, title, description, keywords, charset, prefix, separator and suffix, among others. Note the README's position on keywords: it is a legacy field kept for compatibility and, in the gem's words, ignored by Google Search and Bing web search.
Installing meta-tags and rendering your first title
Add the gem to your Gemfile and install it. The README gives the gem name as meta-tags, quoted, and the command as bundle install.
gem "meta-tags"bundle installNext, generate the initializer if you want to change the shipped defaults for truncation and rendering. The README gives this exact command:
rails generate meta_tags:installThat writes config/initializers/meta_tags.rb. You do not have to run it: the gem ships with practical defaults, and the initializer exists so you can override them.
Now put the rendering call in your main layout. The README's example passes a site name, which becomes the prefix on every page.
<head>
<%= display_meta_tags site: "My website" %>
</head>In a view, set the page title. The README shows the helper returning the string so it can be used as the heading:
<h1><%= title "My page title" %></h1>After rendering, the README's expected output is a document title of "My website | My page title" in the head and "My page title" in the h1. If you want to set several tags at once instead of one helper per tag, use set_meta_tags with a Hash:
set_meta_tags(
title: "Member Login",
description: "Member login page."
)Where meta-tags is the wrong tool
The most concrete limitation is stated by the project itself: meta-tags manages HTML head metadata and does not generate structured data or JSON-LD, robots.txt, sitemaps, internal links, or page content. Teams that need rich results backed by schema.org markup will have to build that separately, and there is no indication in the README that it is planned.
The supported platform is narrow by design. The README says the main branch fully supports Ruby on Rails 6.1 and newer, is tested against all major Rails releases, and no longer supports Ruby older than 3.0 or Rails older than 6.1 because those reached end of life. A Rails 6.0 application on Ruby 2.7 is outside that boundary, and the README does not describe a supported path for it.
There is also a migration hazard in the 2.x line. Symbols inside nested custom tag arrays are treated as literal values today. The README says MetaTags 3.0 will use them to look up normalized top-level tags, and that until then each nested array containing a direct Symbol emits a deprecation warning. You can opt in early with resolve_symbolic_references_in_arrays, but once it is on, String is required for literal array values, and the README notes that a Symbol with no match renders no tag at all. Silent omission is a worse failure than a warning, so this is worth checking before you flip the switch.
Finally, the truncation behaviour of arrays passed to title or keywords is configurable rather than automatic. By default the last item can be cut mid-string. Setting truncate_array_items_at_boundaries to true preserves whole items for multi-item arrays, but the README adds that single-item arrays are still truncated normally. If you assumed boundary-safe truncation applied everywhere, you would be wrong for the single-item case.
meta-tags compared with writing the head by hand
The realistic alternative is not another gem. It is a layout partial with content_for blocks and a handful of helpers, which is what most Rails applications start with. The difference in approach matters more than the feature list.
With a partial, the page title is assembled by string concatenation wherever it is needed, and the canonical URL is whatever the developer remembered to pass in. Nothing enforces consistency, and nothing warns you when a view sets a description that never reaches the head. With meta-tags, set_meta_tags in a view and display_meta_tags in the layout form a single pipeline, and the README's allowed options table becomes the contract for what can be set.
The hand-rolled version wins in one situation: when the metadata is genuinely static, or when the application is small enough that a layout with two conditionals is easier to read than an initializer plus a gem. Adding a dependency to render a fixed title tag is not a trade most teams need to make.
meta-tags also sits below whatever generates your content. It does not know about your routes, your locale files or your database schema beyond the to_meta_tags contract. That keeps it predictable, and it means a page object or presenter that already knows how to describe itself can hand its Hash straight to set_meta_tags without the gem learning anything new.
Maintenance, upgrades and the MIT licence
The repository is not archived, and the last push was on 2026-09-24. The most recent release listed is v2.24.0 on 2026-09-01, following v2.23.0 on 2026-03-16 and v2.22.3 on 2026-01-07. That is a steady cadence with a gap of roughly five months between the last two minor releases, which is worth knowing if you depend on quick turnaround for a specific fix.
The upgrade cost is concentrated in the Symbol handling change. The README frames it as forward compatibility: 2.x treats Symbols in nested custom tag arrays as literal values, 3.0 will resolve them against normalized top-level tags, and you can enable the new behaviour now through resolve_symbolic_references_in_arrays. Enabling it also changes your authoring rules, because literal array values must then be Strings. The README warns that a Symbol with no match renders no tag, so a missed conversion shows up as a missing tag rather than an error.
The gem is MIT licensed, per the repository's MIT-LICENSE file and the licence field. MIT is permissive: it allows commercial and closed-source use, and it requires that the copyright notice and permission notice be included with copies or substantial portions. That is a description of the licence text, not legal advice, and teams with unusual distribution arrangements should read MIT-LICENSE directly. The repository also carries a SECURITY.md, which is the file to consult for how vulnerabilities should be reported.
Editorial conclusion
Adopt meta-tags if you run Rails 6.1 or newer and want head metadata built from controllers, views and model objects rather than hand-written ERB. Skip it if you need JSON-LD structured data, sitemaps or robots.txt, since the README states it generates none of those. Before upgrading past 2.x, verify how your views handle Symbols inside nested custom tag arrays, because the README says each such array currently emits a deprecation warning unless resolve_symbolic_references_in_arrays is enabled.
Frequently asked questions
What does the meta-tags gem actually render?
It renders HTML head metadata: titles, descriptions, canonical links, robots directives, Open Graph tags, X card tags and hreflang links. The README states it does not generate structured data or JSON-LD, robots.txt, sitemaps, internal links or page content.
Which Ruby and Rails versions does meta-tags support?
The README says the main branch fully supports Ruby on Rails 6.1 and newer and is tested against all major Rails releases, and that Ruby older than 3.0 and Rails older than 6.1 are no longer supported because they reached end of life.
How do I install and configure meta-tags in a Rails app?
Add the meta-tags gem to your Gemfile, run bundle install, then run rails generate meta_tags:install to create config/initializers/meta_tags.rb if you want to override the shipped defaults for truncation and rendering.
How do I use meta tags in Rails views and layouts?
Call display_meta_tags in the layout, since the README marks that as required for rendering, and use set_meta_tags or the individual helpers such as title and description in views, where they accept the same arguments but render nothing.
Are meta tags still useful?
meta-tags keeps the keywords field for compatibility, and its README says that field is ignored by Google Search and Bing web search. The gem's stated focus is titles, descriptions, canonicalization, robots directives and social sharing previews.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kpumuk-meta-tags)