Google says my page has a "noindex" tag — but I never added one

Somewhere on your site, Google says, a page carries an instruction — a “tag” — telling search engines not to list it. That is why the page isn’t in Google: not an error, not a penalty, an instruction, followed. And here is the sentence that brings most people to this article: you never wrote any instruction. You may not be sure what a tag even is.

Both of those are normal. In order, then: what the thing is, whether it is actually wrong — and the question the warning never answers, who put it there. Because somebody did.

What it literally says

In Search Console’s page report, the reason reads, word for word:

The line in Search Console

Excluded by ‘noindex’ tag

One note first, because it costs people real time: Google’s own help page for this report calls the same reason “URL marked ‘noindex’”. Two names, one thing — you are in the right place.

What a noindex tag actually is

A tag, here, is not a program and not something attached to your site from outside. It is one line of text inside the page itself, in the part of its code that visitors don’t see. Most of the time it looks exactly like this — the line as Google’s documentation writes it:

<meta name="robots" content="noindex">

robots is the old collective name for the programs search engines send to read pages; the index is Google’s list of pages it can show in results. The whole line is one short sentence addressed to every search engine: you may read this page, but don’t list it. (The same sentence can also ride in the technical header a site sends with each page — a different envelope; it matters later, when you go looking.)

That is the entire event being reported: Google found the line and did what it asked. Nothing malfunctioned. Two questions remain — should the line be there, and who wrote it.

Should it be there? Often, yes

Before hunting for a culprit, open the reason’s row in Search Console and read the addresses — the same move as when Google’s email first arrived: the addresses matter far more than the count. A noindex tag is a tool, and on plenty of pages it is doing exactly the job someone gave it:

• Leave it Thank-you and order-confirmation pages — nobody should land on “thanks for your order!” from a Google search. Correct as is.
• Leave it Checkout, cart, login and admin pages — doors and half-filled forms, not destinations.
• Leave it Your site’s own search results — the pages built when a visitor types into your site’s search box. Endless near-identical lists; keeping them out is the normal choice.
• Leave it A test copy of your site — on a separate practice version, the tag belongs on every page. The trouble is when it becomes the real site and the tag rides along — next section.
• Fix this A page customers should find — home, services, products, contact. There is no good reason for the line to be here.
• One switch Every page at once — not page-by-page bad luck; one site-wide switch, and the next section knows where it lives.

The honest answer, more often than fix-it guides admit, is “this is correct — leave it.” If everything on your list sits in the first four rows, you are done — closing the report is a real decision, not a lazy one.

Who put it there

Here is the heart of it. Almost nobody writes this line by hand. It is nearly always written by software, on the instruction of a checkbox — ticked once, usually during the site’s construction, often by someone other than you, and then forgotten. You are not looking for code someone wrote; you are looking for a box someone ticked.

WordPress has the most famous one. Under Settings → Reading sits “Search Engine Visibility”: a single checkbox, “Discourage search engines from indexing this site.” Tick it and WordPress writes the don’t-list-this line into every page of the site — one click, no confirmation. It gets ticked for a sensible reason — nobody wants a half-built site in Google — and fails to get unticked at launch, because nothing reminds anyone. Notice the careful wording, too: the checkbox says discourage, and WordPress’s documentation adds that “it is up to search engines to honor your request.” Even the vendor calls it a request, not a block — keep that word, it comes back at the end.

SEO plugins are the second suspect on WordPress sites. Yoast, Rank Math, All in One SEO — each has its own set of these switches, one per kind of page, and some arrive already on: tag pages, date archives and author pages are commonly kept out of search by default. Mostly sensible — those are machine-made lists — but it means the “someone” can be a default that shipped inside a plugin, and a per-type switch covers every page of that type.

Squarespace has two, at two levels, and its help page shows both: a per-page toggle — hover the page in the Pages panel, gear icon, SEO tab — called “Hide page from search results”, which writes the one line for you, and a site-wide checkbox labelled “Block Search engine crawlers” (under Settings → Crawlers). That second one is a different tool: Squarespace says it works through robots.txt — the “do not enter” file that gets its own section below — not by writing the tag.

Wix has the same two kinds of switch, per page and site-wide, both worded around whether search engines may index the page.

Shopify is the interesting exception: no simple hide-from-search checkbox on ordinary pages. Its help page documents three routes instead — editing the theme’s code, marking a product Unlisted, or a hidden setting called a “metafield” that developers and apps can flip. So an unexplained noindex there rarely points at a checkbox you forgot; it points at whoever built or edited your theme, at a product someone marked Unlisted, or at something on your installed-apps list. Ask the developer; read the app list.

Across all of them, the tag’s biography is usually the same three lines: switched on while the site was being built — sensibly; site went live; nobody remembered the switch existed. One reasonable click, and the click outlived its reason.

See it with your own eyes

You don’t have to take Search Console’s word for any of this — it is one of the few warnings you can verify yourself, in under a minute, with nothing but a browser.

Open the affected page, right-click anywhere, and choose View page source. A wall of code appears; you are not going to read it. Press Ctrl+F (Cmd+F on a Mac), type noindex, and hit Enter. Either the word lights up — usually near the top, in a line like the one shown earlier — or it is not there at all.

One footnote: the envelope version — the header, not the page itself — won’t show in page source. The tool that sees both is URL Inspection, at the top of Search Console — paste the page’s address and it tells you whether indexing is allowed on that page. Test live URL answers for the page as it is this second, not as Google last saw it.

One trap before you fix anything

Sooner or later you will meet robots.txt — a small file that tells search engines which parts of a site not to visit. Adding it on top of noindex sounds like a second lock. Google’s documentation says the pair does the opposite of what you’d expect:

Google’s documentation — “the crawler” is Google’s page-reading program

For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler. If the page is blocked by a robots.txt file or the crawler can’t access the page, the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it.

In plain words: robots.txt is a “do not enter” sign on the door, and noindex is a note lying inside the room. Hang the sign and Google doesn’t enter — so it can’t read the note — and a page it has heard about from elsewhere can still surface in results. So, backwards from intuition: to keep a page out of Google, use noindex and leave the door open. And to bring one back in — or to have anyone notice a tag you’ve removed — the sign has to come down too.

The fix, and the two dates

If the tag is wrong, the fix is usually one action: find the switch above and turn it off. Then see with your own eyes that the line is gone — page source again, or the live test. Switch names and switch coverage don’t always match, and thirty seconds of looking beats weeks of wondering.

Back in Search Console, Validate fix is worth pressing — just know what it starts: a slow re-reading of the affected pages that can run for weeks. If it ends in “Failed”, that verdict has its own article — one leftover page fails the whole batch.

Now the part every quick guide leaves out. Removing the tag does not put the page back. Google took the page out because it read an instruction; it puts the page back only when it reads the page again and finds the instruction gone. Until that visit, your change doesn’t exist, as far as Google knows. Its documentation is blunt about the timescale:

Google’s documentation — written about adding the tag, but the road runs both ways

We have to crawl your page in order to see <meta> tags and HTTP headers. If a page is still appearing in results, it’s probably because we haven’t crawled the page since you added the noindex rule. Depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page.

That paragraph describes the opposite journey — a page still showing after the tag was added — but the mechanic is symmetrical, and no timeframe is promised either way. Remember WordPress’s word: request. Unticking the box is a request too, granted at Google’s next visit, not yours.

So “I fixed it” and “it’s back in Google” are two different dates, and only the first is yours to set. Between them the report keeps showing the old warning — not because your fix failed, but because nobody has been by to see it. The live test proves your half today: the line is gone. The other half sits on Google’s calendar. Elsewhere in this series, gone isn’t the same as fixed; this warning teaches the same lesson in reverse — fixed isn’t the same as back.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.