Technical SEO Field Reference, Question 19 of 66. The interview answer, checked against what Google currently documents.
Google has to fetch a page before it can read its noindex rule or canonical annotation. If robots.txt blocks that fetch, Google cannot see either instruction in the current response. When crawling is allowed, noindex controls whether the page can appear in search, while canonicalisation helps Google choose a representative URL for duplicate content. Google’s documentation does not give a simple winner for noindex combined with a canonical pointing elsewhere. Diagnosing conflicting signals starts with checking what Google can actually read.
A page has a noindex tag. Its canonical points to another URL. The folder is also disallowed in robots.txt.
An interviewer asks which one wins.
I would start by checking whether Google can fetch the page. Until I know that, I do not know which instructions it can read.
Why conflicting signals happen
It is easy to see how a site ends up here.
Someone adds canonicals to consolidate duplicate URLs. Later, some of those URLs still appear in Google, so someone adds noindex to the template. A crawl-budget project then blocks the folder in robots.txt.
Each change has a reason behind it. But the crawl block prevents Google from seeing the instructions added to the page.
The CMS can show all the settings you intended to apply while Google sees only part of them. That is where I would begin the investigation.
What Google says about conflicting signals
Google’s robots documentation says meta robots tags and X-Robots-Tag headers are discovered through crawling. If robots.txt disallows the URL, those rules “will not be found and will therefore be ignored”.
It also says that, for conflicting robots rules, “the more restrictive rule applies”. The example is max-snippet alongside nosnippet. I would apply that statement to robots rules; it does not establish precedence over canonical annotations.
The earlier question on noindex blocked by robots.txt covers the crawl-block interaction in more detail.
Google’s canonical guidance says not to use robots.txt for canonicalisation. A disallowed URL can still be indexed without its content. It also advises against using noindex to influence canonical selection within the same site, recommending rel=”canonical” for that purpose.
The A/B testing guidance gives a specific example. For test URLs that are variations of an original page, Google recommends canonical annotations. It warns that using noindex instead “can sometimes have unexpected bad effects”. That warning concerns the testing setup; it does not define a universal winner when both signals appear together.
The interview answer for conflicting signals
I would answer it like this:
I would check crawl access first. If robots.txt blocks the URL, Google cannot fetch the current page to read its noindex or canonical.
If crawling is allowed, I would check what the URL is meant to do. Noindex asks for exclusion from search. A canonical identifies a preferred version of duplicate content, which Google assesses alongside other signals.
Google does not document a simple winner for that combination. I would remove the conflicting instructions, then check whether Google processes the URL as intended.
Conflicting signals at a glance
The distinction between documented behaviour and inference is worth keeping in the answer. Otherwise, an explanation of how crawling works can turn into a claim Google has not made.
A filter URL example with conflicting signals
Say a retailer has 40,000 filter URLs, including /dresses/?colour=green. Each carries a canonical pointing to /dresses/.
Someone blocks the colour parameter to reduce crawling. Some filter URLs still appear in Google, so noindex is added to the template.
Google cannot fetch the blocked pages to discover the new noindex. It also cannot revisit them to read the current canonicals. Any canonical signals Google already knew about do not tell us whether it has seen the latest implementation.
Before changing anything, I would inspect a sample in Search Console. I would check crawl access and the last crawl date, then compare the declared and Google-selected canonicals wherever those fields are available.
I would also check whether these filtered pages are similar enough to /dresses/ for that canonical to make sense. The presence of a canonical tag does not establish that the target is appropriate.
The decision about which filter URLs should be crawlable or indexable belongs in the wider faceted navigation strategy.
How I would work through conflicting signals
I use the following as a diagnostic model. It is a way to organise the checks, not a diagram of Google’s internal processing.
Start with crawl access. Then inspect what the response actually serves, including HTTP headers. Once I know what Google can read, I can assess whether those instructions support the intended outcome.
For duplicate consolidation, I would allow crawling, keep an appropriate canonical and remove the noindex. I would also check that internal links and sitemaps support the preferred URL.
For exclusion from search, I would keep the page crawlable so Google can process noindex. I would not pair that with a canonical pointing elsewhere as part of the removal strategy. The question on how to deindex internal search pages explains the order of work.
If the aim is simply to prevent fetching, Disallow serves that purpose. I would account for the possibility that the URL could still appear in search.
There can also be conflicting canonical signals without any robots rule involved. Google advises against declaring different canonical URLs through different methods, such as a sitemap and a page annotation.
What I would check in Search Console for conflicting signals
I would inspect URLs from the affected pattern, including examples behaving as expected. That gives me something to compare with the problem URLs.
In URL Inspection, I would look at:
- Whether crawling and indexing are allowed.
- The last crawl date.
- The user-declared and Google-selected canonicals, where available.
A different Google-selected canonical needs investigation. It does not, by itself, prove the page is configured incorrectly.
Then I would read the live robots.txt and fetch a sample URL, including its response headers. Those checks show what the site serves now. Search Console helps establish what Google last processed.
I would trust that evidence over a CMS settings screen. A setting can be correct in the admin interface and still produce the wrong response.
The interview trap on conflicting signals
“Robots.txt overrides noindex” is a tempting answer. It leaves out the mechanism: the crawl block prevents Google from reading the noindex.
“Noindex beats canonical” goes further than the documentation supports.
I would expect a candidate to explain which instructions Google can see, identify the outcome the site needs and describe how they would verify the change. Calling everything unpredictable does not get us very far either. Some interactions are documented, and others need a clearly labelled inference.
Takeaway
Check whether Google can fetch the URL before changing the instructions on it.
Then decide whether the URL should be consolidated, excluded from search or blocked from crawling. Apply the controls for that purpose and verify what Google processes after the change.
Have questions about this topic? Contact The GEO Lab · Return to homepage