A page is indexable before you buy only if three things are clear: no noindex directive in the page or its HTTP response, a canonical link that points to the page itself, and no robots.txt rule that blocks the section holding it. If any of the three fails, the link you pay for will not sit on a page Google shows in results, however good the article looks. The test takes a browser and a few minutes, and it suits site owners, online sellers and agencies that buy backlinks or sponsored posts.
The test covers what can be caught before an order. Whether Google has actually indexed a published page is a separate question, answered after publication with its own evidence.
Four traps, and why you check them before paying
Indexing problems are quiet. A page can look perfect in a browser and still carry a rule that keeps it out of search results. Four traps account for the cases buyers run into: a noindex meta tag, an X-Robots-Tag header, a canonical that points elsewhere and a robots.txt block. They are checked before payment because afterwards you have already paid and lost bargaining power.
Indexable and indexed are different
An indexable page has no rule that stops it from being indexed. An indexed page is one Google has actually added. A newly published post may not be indexed yet and still be indexable. This check concerns the first property. The evidence log for the second belongs to the guide on how to check that a backlink page is indexed.
Which page to test
If the seller offers a placement on the site in general, ask for a recent post from the same template and section. If your page does not exist yet, the example post shows the rules your page will inherit. A clean home page proves little, because the post section can follow different rules.
What you need
A browser, the page source view, the address of the site's robots.txt file and the network tab of the browser's developer tools, which shows response headers.
Trap one: the noindex meta tag
Google's robots meta tag documentation (Opens in a new tab) says noindex means the page should not be shown in search results, and it says nofollow means the links on the page should not be followed.
How to look
Open the page source and search for a meta tag named robots or googlebot. If its content contains noindex, the page will stay out of results. No tag at all is fine: without directives, the page can be indexed. If the tag also contains nofollow, links on the page are not meant to be followed, which matters for a link you are paying for and should be raised with the seller.
Dated pages
The documentation also describes unavailable_after, which stops the page appearing in results after a given date and time. If a post carries it, the post is a time-limited page. For a placement meant to last, treat it as a warning.
Trap two: the X-Robots-Tag header
The same documentation says the X-Robots-Tag can be used as an element of the HTTP header response for a given URL, and it recommends the header for non-HTML files such as PDFs.
Why the page source misses it
A header is not part of the page markup. A page can have a spotless source and still return an X-Robots-Tag: noindex header. Open the network tab of the developer tools, reload the page, select the page request and read its response headers. That is the only reliable way for a buyer to see this trap. The longer explanation is in the noindex tag and X-Robots-Tag guide.
When directives conflict
The documentation says that when rules conflict, the more restrictive one applies. A page with noindex in one place and an indexing-friendly rule in another is still noindex for practical purposes.
Trap three: a canonical that points elsewhere
Google's documentation on consolidating duplicate URLs (Opens in a new tab) describes the rel canonical link annotation as a strong signal that the specified URL should become canonical. It advises including a canonical link on the canonical page itself and says that none of the canonicalization methods are required. It lists redirects as a strong signal and sitemap inclusion as a weak one.
What it means for a buyer
If the post's canonical points to a different address, Google may prefer that other address for its index. Your link would then sit on a page that is not the version being shown. Because the documentation calls canonical a signal, not a command, the outcome is a probability, not a certainty. It is still enough to stop and ask.
Mistakes worth recognising
The documentation recommends absolute paths over relative ones, advises against specifying a URL fragment as canonical, and warns against giving different canonical addresses for the same page through different methods. It suggests choosing either the HTTP header or the link element, not both. A buyer does not fix these, but a broken or contradictory canonical is a fair reason to write to the seller. The canonical tag issues guide covers the detail.
Canonical together with noindex
The same page advises against using noindex to choose a canonical within a site, because noindex blocks the page completely. If you find both on one page, noindex is the stronger problem.
Trap four: a robots.txt block
A robots.txt file tells crawlers which paths they may fetch. If the post section is disallowed, Google does not crawl those pages.
Why the other traps become invisible
The robots meta tag documentation states that when robots.txt blocks crawling, Google cannot find the page's meta tags or headers, so any rules in them are ignored. Two consequences follow. A noindex on a blocked page is never seen, and a clean page that is blocked is still not crawlable. Being able to open a page in your browser says nothing about Google's access.
How to read the file
Add robots.txt to the site's root address and read the Disallow lines. Check whether the path of the posts, for example the blog section, is disallowed, and note which user-agent each rule applies to. If the file is hard to read, ask the seller to confirm in writing that the sample post is open to crawling.
Do not use robots.txt for canonicalization
The duplicate URL documentation tells site owners not to use robots.txt for canonicalization purposes. If a seller says a page is hidden from Google but its canonical is fine, two different mechanisms are being confused.
What this test cannot show
The test reads the page's technical state today. It cannot guarantee that Google will index the page, since the documentation describes methods such as canonical as signals and says Google may make its own choice. The seller can also edit the page after the order, so the post-publication check and indexing evidence should be planned as a separate step. Google's wording can change, so read the live pages before applying them.
The test in order, step by step
Reading each trap in isolation works, but a fixed order produces comparable results across sites. All steps use public information and need no tools beyond a browser.
One: choose two posts
Ask the seller for a sample post, then pick a second recent post yourself. A seller may show only the cleanest page. Record both addresses.
Two: meta tags in the source
Search the source of each post for meta tags named robots or googlebot. Note the content exactly as written, or write "no tag". Writing "no tag" is a positive finding and belongs in the record.
Three: the canonical link
Find the link element with rel canonical and compare its address with the address bar. Look at the domain, the protocol, the trailing slash, parameters and the path. Small differences can point to a template problem.
Four: the response headers
Open the network tab, reload the page and read the response headers of the first request. Look for an X-Robots-Tag line and copy its value, or write that it is absent.
Five: the robots.txt file
Open robots.txt at the site root and read the Disallow lines. Check whether the path of the posts is covered, and note the user-agent each rule applies to.
Six: record the result
Combine the findings in one note. Noindex, X-Robots-Tag or a robots.txt block means reject. A different canonical means hold. Everything clear means pass.
Seven: run it again another day
Run the same steps on a different day. Consistent results settle the decision. If they differ, record the worse result and ask the seller to explain.
Special cases
Archives and tags
If your link will sit on a category or tag archive page and not on a post, test the rules of that archive page. A site may mark archive pages noindex on purpose. For such an offer, run the test against the page type you will actually be placed on.
Non-HTML files
If the link is inside a PDF, the X-Robots-Tag header is what matters, since the documentation says to use that header for non-HTML files such as PDFs. The network-tab check is then a required step.
Subdomains and site sections
Different sections or subdomains of one site can follow different rules. Run a separate sample post and a separate robots.txt reading for each. One clean section says nothing about the others.
The traps in one table
| Trap | Where it appears | Why it matters | Suggested outcome |
|---|---|---|---|
| noindex meta tag | Robots meta tag in the page source | Page not shown in results | Reject |
| X-Robots-Tag header | Response headers in the network tab | Same effect, invisible in the source | Reject |
| Canonical to another URL | Link element in the page source | Google may prefer the other address | Hold until the right address is confirmed |
| robots.txt block | The site's robots.txt file | Tags unseen and the page not crawled | Reject |
| unavailable_after | Meta tag or header | Page leaves results after a date | Hold, reject if the placement must be permanent |
Putting the proof into the order note
A result without written proof does not help in a later dispute. Keep the proof simple and dated.
Note template
- Address checked and date of the check.
- Robots meta tag in the page source: none, or the directive itself.
- X-Robots-Tag in the response headers: none, or its value.
- Canonical address: the page itself, or another address.
- Status of the path in robots.txt: open or blocked.
- Who checked, and the outcome: pass, hold or reject.
Screenshot and source record
Save the relevant source lines and the header list from the network tab as images. If the seller changes anything after publication, you have a point of comparison.
Written confirmation
Ask the seller to confirm in writing that the section has no noindex, no X-Robots-Tag, no robots.txt block and no canonical to another address. The confirmation is not a replacement for your proof, but it clarifies responsibility if something changes.
Decision: browser source or Search Console URL Inspection first
The open question is whether the pre-check should lead with browser source or with the Search Console URL Inspection tool. Practical suggestion: lead with the browser source and the response headers. URL Inspection needs a property you manage, and before ordering you have no such access to the seller's site. Source and headers are public on every site. When the page belongs to your own property, URL Inspection adds a second confirmation. Search Console labels may look different if your interface is in another language.
The rule in five lines
- A noindex meta tag or an X-Robots-Tag header: reject.
- A robots.txt block on the sample post path: reject.
- A canonical pointing to another address: hold until the right address is confirmed in writing.
- unavailable_after on a placement that must last: hold or reject.
- All four clear: indexability passes, so move on to the other checks.
Checklist before you order
- Did you obtain a sample post from the same template?
- Did you search the page source for robots and googlebot meta tags?
- Did you read the response headers for X-Robots-Tag?
- Did you compare the canonical address with the page's own address?
- Did you check the post path in robots.txt?
- Did you look for directives such as unavailable_after?
- Did you add the date, screenshot and result to the order note?
- Did you repeat the check on a different day?
Example scenario: an online garden-tools shop
Example scenario: A shop selling garden tools is offered a sponsored post on a home-improvement blog. Its owner opens a sample post and views the source. There is no robots meta tag and the canonical equals the page address. In the network tab, however, the response headers include X-Robots-Tag: noindex. The source alone would have passed the page, and the header check catches it. The outcome is reject.
On a second blog the owner finds no meta tag, clean headers and an open robots.txt, but the canonical points to the blog's home page. The outcome is hold. The seller explains that it is a template fault, fixes it and confirms in writing. The owner repeats the check the next day, sees the canonical now matches the page, and moves on to the technical and history checks.
Questions to send the seller
Some facts only the seller can confirm. Send the questions in writing and keep the answers.
- Does the section where my post will appear carry noindex, an X-Robots-Tag header, a robots.txt block or a canonical to another address?
- Will the post be taken down or hidden from results after a certain date?
- If the template or rules change after publication, will you tell me?
- If the post is not indexable after publication, what correction do you offer?
Making sense of replies
A general reply such as "there is no problem on our site" does not settle the matter. Ask for confirmation about the specific section and sample post. A seller who dodges earns a hold. If the seller admits a problem and offers a fix, get the date and method in writing, then repeat the test.
A second look once the link is live
The test is not one-and-done. A seller can update the site, change the template or install a plugin, and each of these can add a directive.
What to open again
The robots meta tag, the response headers, the canonical address and the relevant part of robots.txt, compared with the record made on the publication date.
When a signal has moved
If a purchased page later gains noindex, ask for a correction under the order terms. When the terms were never written down, the request has a weak footing, which is one more reason to keep the test note and the seller's written confirmation. Collecting proof of indexing after publication is a separate step.
Rhythm of rechecks
The documentation sets no interval. Practical suggestion: check shortly after publication, tie later checks to your reporting cycle and write each date in the record.
Mistakes at a glance
| Mistake | What goes wrong and what to do |
|---|---|
| Reading only the page source | The X-Robots-Tag header never appears in the markup. Look at the headers in the network tab as well. |
| Testing the home page instead of a post | The home page can be clean while the post section follows different rules. Test a sample post. |
| Confusing a robots.txt block with a clean page | A page without noindex but blocked in robots.txt is not crawlable. Do not read the missing tag as safety. |
| Relying on one check | Templates and rules change. Repeat the check on another day. |
Summing up the result in one sentence
The sentence that goes into the record is the line people read first, so keep it short, concrete and tied to evidence. For example: "Reject: post section marked noindex through an X-Robots-Tag header, confirmed on two days." Detail stays in the attached screenshot and source note.
Working for clients
For agencies, indexability is the cheapest and first filter. A shared table of results lets the team avoid rechecking the same site for different clients without a reason.
What goes in the log
Address, check date, meta tag result, header result, canonical result, robots.txt result, decision and the place where the evidence is stored.
Scheduling a second look
Redo the check for every repeat order. A template can change, and a section that was open yesterday can carry noindex today. The date in the record tells you when it changed.
Reporting to the client
Write the concrete block in the report, for example: "Post section is marked noindex through an X-Robots-Tag header." One factual sentence shows that the decision came from evidence.
Frequently Asked Questions
If the page source has no noindex tag, is the page indexable?
Not necessarily. The same directive can arrive in the X-Robots-Tag HTTP header, which does not appear in the source. Check the response headers in the network tab, and also check robots.txt and the canonical.
What happens if the canonical points to another page?
Google's documentation calls rel canonical a strong signal that the specified URL should become canonical. The page holding your link may then not be the version Google prefers. It is a signal, not a certainty, but it is reason enough to hold.
If robots.txt blocks a page that has noindex, does Google see it?
No. According to Google's robots meta tag documentation, when robots.txt blocks crawling the page's meta tags and headers cannot be found, so any rules in them are ignored.
Which directive wins when rules conflict?
The documentation says the more restrictive rule applies. If you find noindex anywhere, an indexing-friendly rule elsewhere does not rescue the page.
Should I start with Search Console URL Inspection?
As a practical suggestion, start with the browser source and response headers. URL Inspection needs a property you manage, which you do not have for a seller's site before ordering.
How often should I run the check?
The documentation gives no number. As a practical suggestion, run it on at least two different days and write each date in the order note, because templates can change.
Conclusion
Checking indexability before you buy catches three families of problems: noindex and X-Robots-Tag, a canonical pointing elsewhere and a robots.txt block. The source is not enough, so read the response headers too, and remember that a robots.txt block hides every tag on the page from Google. Decide pass, hold or reject, add dated proof to the order note and repeat the check on another day. The test promises no ranking, but it exposes a blocker before money changes hands. If you want to look at ready-made options afterwards, the backlink packages page on Akua Adforce lists scope and terms.
Post a comment
Please log in to leave a comment. Login