[wp-trac] [WordPress Trac] #52900: Instantly index WordPress web sites content in Search Engines

[WordPress Trac]

#52900: Instantly index WordPress web sites content in Search Engines
-------------------------------------------------+-------------------------
 Reporter:  fabricecanel                         |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  reporter-feedback has-patch has-     |     Focuses:
  unit-tests                                     |
-------------------------------------------------+-------------------------

Comment (by dd32):

 @fabricecanel Can you please edit/delete any comments above that were made
 in error? It looks like you're quoting entire comments from above without
 adding any extra context or answers - or you might've, but it's inline
 with another comment? I'm not sure I can't tell :)

 > Next month, we will disclose far more on wide industry support.

 Thank you! That makes a huge difference, and helps this proposal as it's
 taken it from being a niche single-supporter use-case (Which would not be
 welcome in WordPress IMHO) to a industry-lead proposal which has a much
 better chance of support.

 To provide some kind of code review on the approach taken:
  - I'm still not 100% convinced that having WordPress ping each of the
 engines individually is ideal, however, it's not the worst.
  - I'm still not 100% convinced that having an API key / verification
 callback should be allowed.
  - All supported providers would need to be defaulted in core, so as not
 to preference any given engine
  - No code-based configuration should be required for an end-user, at the
 most, a textarea with a list of search engine endpoints
  - No "exclude paths" functionality would be supported in a UI, filters
 should be exposed to add that
  - The `WP_IndexNow_Provider` class `consts` should probably be removed
 and put inline, other than perhaps
 `WP_IndexNow_Provider::SUBMIT_API_PATH`.
  - Same for the `WP_IndexNow` class `consts` - consting them doesn't help
 readability here at all, and only makes it harder to parse what the
 methods do.
  - `WP_IndexNow::check_for_indexnow_page()` should probably work the same
 way that the robots.txt loading works, through a rewrite rule. Speaking
 of, this also shows that indexnow doesn't work for WordPress sites which
 don't use URL rewrites. Potentially this is a shortcoming in the indexnow
 standard and it should be providing a unique call-back URI or `/.well-
 known/` url as part of the ping payload, rather than just assuming
 `https://example.com/base64-api-key-here.txt`.

 Finally:
  - I think this should be developed as a plugin first, and then proposed
 to WordPress core as a feature plugin, to allow development of it to occur
 separately and then a suggestion to add it to core once feature complete.
 That would also allow site owners to opt-in to using this prior to
 WordPress fully implementing it (Which would be in WordPress 6.0 at the
 absolute earliest, Q2ish 2022 at a guess)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52900#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform