Undo #59 and never prevent indexing or move it to a separate config

[vpillinger]

Submit a feature request or bug report

• I've read the guidelines for Contributing to Roots Projects
• This is a feature request
• This is a bug report
• This request isn't a duplicate of an existing issue
• I've read the docs and followed them (if applicable)

Replace any X with your information.

---

What is the current behavior?

When the site is in not in production mode indexing is prevented by a wordpress hook. This also prevents indexing in say case where environment is accidentally set to "productoin". Which is undesirable because a simple mistake or typo can silently wreck an seo ranking.

What is the expected or desired behavior?

The site should never prevent indexing unless explicitly told to and with a warning displayed.

Some options include 1) Moving it to a separate config and displaying a warning in wp-admin when it is not in allowing indexing, or 2) removing it entirely.

---

Feature Request

Please provide use cases for changing the current behavior:

1. This is a potential source of serious SEO trouble. Inexperienced developers, unattentive server admins, or just human error make it very likely that a site's SEO ranking gets wiped. There is no visible warning or display that the site is not indexing information, and in the kind of teams that make these configuration mistakes, it is unlikely to be found until it is too late.

2. It is better to disallow indexing and protect from access by bots by using basic auth. Unsavory bots can still find your site and ignore the meta tag with the current implementation. Basic auth is also much more visible and will be corrected quickly in production.

Other relevant information:

[austinpray]

I agree that the config for this should be explicit. application.php and environments/*.php should clearly represent everything that is going on with bedrock configuration-wise.

I know for a fact personally when I use bedrock I try to avoid "WP_ENV ==='production'" as much as possible. "WP_ENV === 'development'" for enhanced debugging, dev affordances is tolerable to me but never === production.

As I said in #371 (comment) this might be possible with #380

[ethanclevenger91]

Couldn't you make the exact opposite argument though? That failing to explicitly disable search indexing could wreck SEO due to having an entire copy of your website being indexed?

[austinpray]

Maybe I wasn't clear/you didn't understand that I am trying to determine a fail-safe case.

I'm suggesting:

• to application.php add the following line Config::define('DISALLOW_INDEXING', WP_ENV !== 'production');. This means all environments will disallow indexing by default except for production.
• make the disallow indexing plugin listen to the DISALLOW_INDEXING env var instead of WP_ENV directly

Now everyone can explicitly control the fail-safe in application.php, the new one important place to look for bedrock configuration. If you want you could do like Config::define('DISALLOW_INDEXING', in_array(WP_ENV, ['staging', 'development'])); if you are like OP and you are scared

[ethanclevenger91]

I gotcha, so this doesn't change the current behavior. I like the granularity of control offered here.

…

On Wed, Dec 5, 2018 at 2:58 PM Austin Pray ***@***.***> wrote: Maybe I wasn't clear/you didn't understand that I am trying to determine a fail-safe case. I'm suggesting: - to application.php <https://github.com/roots/bedrock/blob/61e5689f8d5308fac3c8f9da714c627252bc8e19/config/application.php#L90> add the following line Config::define('DISALLOW_INDEXING', WP_ENV !== 'production');. This means all environments will disallow indexing by default except for production. - make the disallow indexing plugin listen to the DISALLOW_INDEXING env var instead of WP_ENV directly Now everyone can explicitly control the fail-safe in application.php, the new one important place to look for bedrock configuration. If you want you could do like Config::define('DISALLOW_INDEXING', in_array(WP_ENV, ['staging', 'development'])); if you are like OP and you are scared — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#368 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACgInpdmk9FWKQFuXSdLMtg75GGRczcPks5u2E-lgaJpZM4Vo76R> .

[swalkinshaw]

Closed by #521