-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undo #59 and never prevent indexing or move it to a separate config #368
Comments
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 |
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? |
Maybe I wasn't clear/you didn't understand that I am trying to determine a fail-safe case. I'm suggesting:
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 |
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>
.
|
Closed by #521 |
Submit a feature request or bug report
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:
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.
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:
The text was updated successfully, but these errors were encountered: