diff --git a/docs/basics/101-101-create.rst b/docs/basics/101-101-create.rst
index 78efb3c85..673cf5350 100644
--- a/docs/basics/101-101-create.rst
+++ b/docs/basics/101-101-create.rst
@@ -19,7 +19,7 @@ useful features.
 Because experiencing is more insightful than just reading, we will explore the
 concepts of DataLad datasets together by creating one.
 
-.. index:: ! datalad command; create
+.. index:: ! DataLad command; create
 
 Find a nice place on your computer's file system to put a dataset for ``DataLad-101``,
 and create a fresh, empty dataset with the :dlcmd:`create` command.
diff --git a/docs/basics/101-102-populate.rst b/docs/basics/101-102-populate.rst
index 1a2fd832c..e00770a4e 100644
--- a/docs/basics/101-102-populate.rst
+++ b/docs/basics/101-102-populate.rst
@@ -106,7 +106,7 @@ structure with tree:
 
    $ tree
 
-.. index:: ! datalad command; status
+.. index:: ! DataLad command; status
 
 Now what does DataLad do with this new content? One command you will use very
 often is :dlcmd:`status`.
@@ -121,7 +121,7 @@ regular status reports should become a habit in the wake of ``DataLad-101``.
 
    $ datalad status
 
-.. index:: ! datalad command; save
+.. index:: ! DataLad command; save
 
 Interesting; the ``books/`` directory is "untracked". Remember how content
 *can* be tracked *if a user wants to*?
diff --git a/docs/basics/101-105-install.rst b/docs/basics/101-105-install.rst
index 0398a7bd9..cb6a08068 100644
--- a/docs/basics/101-105-install.rst
+++ b/docs/basics/101-105-install.rst
@@ -1,4 +1,4 @@
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 .. _installds:
 
 Install datasets
@@ -55,7 +55,7 @@ called recordings.
    $ mkdir recordings
 
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 The command that can be used to obtain a dataset is :dlcmd:`clone`,
 but we often refer to the process of cloning a Dataset as *installing*.
@@ -238,7 +238,7 @@ hard drive has much space left...
 But you nevertheless are curious on how to actually listen to one of these ``.mp3``\s now.
 So how does one actually "get" the files?
 
-.. index:: ! datalad command; get
+.. index:: ! DataLad command; get
 
 The command to retrieve file content is :dlcmd:`get`.
 You can specify one or more specific files, or ``get`` all of the dataset by
@@ -315,7 +315,7 @@ of file contents in dataset, too?", they ask. "Yes", the lecturer responds,
 "you can remove file contents by using :dlcmd:`drop`. This is
 really helpful to save disk space for data you can easily re-obtain, for example".
 
-.. index:: datalad command; drop
+.. index:: DataLad command; drop
 
 The :dlcmd:`drop` command will remove
 file contents completely from your dataset.
diff --git a/docs/basics/101-106-nesting.rst b/docs/basics/101-106-nesting.rst
index 2cc8c4045..d562f56a4 100644
--- a/docs/basics/101-106-nesting.rst
+++ b/docs/basics/101-106-nesting.rst
@@ -1,10 +1,12 @@
+.. index:: ! DataLad dataset; nesting
+
 .. _nesting:
 
+.. index:: ! DataLad dataset; nesting
+
 Dataset nesting
 ---------------
 
-.. index:: ! nesting
-
 Without noticing, the previous section demonstrated another core principle
 and feature of DataLad datasets: *Nesting*.
 
diff --git a/docs/basics/101-107-summary.rst b/docs/basics/101-107-summary.rst
index 589c854f7..d2cfe1732 100644
--- a/docs/basics/101-107-summary.rst
+++ b/docs/basics/101-107-summary.rst
@@ -48,7 +48,7 @@ and making simple modifications *locally*.
 Furthermore, we have discovered the basics of installing a published DataLad dataset,
 and experienced the concept of modular nesting datasets.
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 * A published dataset can be installed with the :dlcmd:`clone` command:
 
diff --git a/docs/basics/101-108-run.rst b/docs/basics/101-108-run.rst
index 126c91418..810e043a5 100644
--- a/docs/basics/101-108-run.rst
+++ b/docs/basics/101-108-run.rst
@@ -155,7 +155,7 @@ in a bit of time, we will forget how this file came into existence, or
 that the script ``code/list_titles.sh`` is associated with this file, and
 can be used to update it later on.
 
-.. index:: ! datalad command; run
+.. index:: ! DataLad command; run
 
 The :dlcmd:`run` command
 can help with this. Put simply, it records a command's impact on a dataset. Put
diff --git a/docs/basics/101-109-rerun.rst b/docs/basics/101-109-rerun.rst
index 27f333bc2..491ca3c9e 100644
--- a/docs/basics/101-109-rerun.rst
+++ b/docs/basics/101-109-rerun.rst
@@ -3,7 +3,7 @@
 DataLad, re-run!
 ----------------
 
-.. index:: ! datalad command; rerun
+.. index:: ! DataLad command; rerun
 
 So far, you created a ``.tsv`` file of all
 speakers and talk titles in the ``longnow/`` podcasts subdataset.
@@ -158,7 +158,7 @@ we can see that a new :dlcmd:`run` was recorded. This action is
 committed by DataLad under the original commit message of the ``run``
 command, and looks just like the previous :dlcmd:`run` commit.
 
-.. index:: ! datalad command; diff
+.. index:: ! DataLad command; diff
 
 Two cool tools that go beyond the :gitcmd:`log`
 are the :dlcmd:`diff` and :gitcmd:`diff` commands.
diff --git a/docs/basics/101-110-run2.rst b/docs/basics/101-110-run2.rst
index 78d7b5d8e..635d5ee5d 100644
--- a/docs/basics/101-110-run2.rst
+++ b/docs/basics/101-110-run2.rst
@@ -239,7 +239,7 @@ In the attempt to resize the image to 450x450 you tried to overwrite
 ``recordings/salt_logo_small.jpg``, a file that was given to DataLad
 and thus protected by git-annex.
 
-.. index:: ! datalad command; unlock
+.. index:: ! DataLad command; unlock
 
 There is a DataLad command that takes care of unlocking file content,
 and thus making locked files modifiable again: :dlcmd:`unlock`.
diff --git a/docs/basics/101-115-symlinks.rst b/docs/basics/101-115-symlinks.rst
index d3a7313a2..c63dceec2 100644
--- a/docs/basics/101-115-symlinks.rst
+++ b/docs/basics/101-115-symlinks.rst
@@ -278,11 +278,11 @@ to manage the file system in a DataLad dataset (:ref:`filesystem`).
    Maybe you are as amazed as we are about some of the ingenuity used behind the scenes.
    Even more mesmerizing things about git-annex can be found in its `documentation <https://git-annex.branchable.com/git-annex>`_.
 
+.. index:: ! broken symlink, ! symlink; broken
+
 Broken symlinks
 ^^^^^^^^^^^^^^^
 
-.. index:: ! broken symlink, ! symlink (broken)
-
 Whenever a symlink points to a non-existent target, this symlink is called
 *broken*, and opening the symlink would not work as it does not resolve. The
 section :ref:`filesystem` will give a thorough demonstration of how symlinks can
diff --git a/docs/basics/101-116-sharelocal.rst b/docs/basics/101-116-sharelocal.rst
index dcb905dba..f8841aa97 100644
--- a/docs/basics/101-116-sharelocal.rst
+++ b/docs/basics/101-116-sharelocal.rst
@@ -81,7 +81,7 @@ home directory. Furthermore, let's for now disregard anything about
 :term:`permissions`. In a real-world example you likely would not be able to read and write
 to a different user's directories, but we will talk about permissions later.
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 After creation, navigate into ``mock_user`` and install the dataset ``DataLad-101``.
 To do this, use :dlcmd:`clone`, and provide a path to your original
@@ -134,7 +134,7 @@ object tree. To reassure your room mate that everything is fine you
 quickly explain to him the concept of a symlink and the :term:`object-tree`
 of :term:`git-annex`.
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 "But why does the PDF not open when I try to open it?" he repeats.
 True, these files cannot be opened. This mimics our experience when
diff --git a/docs/basics/101-119-sharelocal4.rst b/docs/basics/101-119-sharelocal4.rst
index a04ae4153..abd749755 100644
--- a/docs/basics/101-119-sharelocal4.rst
+++ b/docs/basics/101-119-sharelocal4.rst
@@ -50,7 +50,7 @@ it can query the original dataset whether any changes
 happened since the last time it checked, and if so, retrieve and
 integrate them.
 
-.. index:: ! datalad command; update
+.. index:: ! DataLad command; update
 
 This is done with the :dlcmd:`update --how merge`
 command.
diff --git a/docs/basics/101-121-siblings.rst b/docs/basics/101-121-siblings.rst
index 78a15f3d9..08f35e92f 100644
--- a/docs/basics/101-121-siblings.rst
+++ b/docs/basics/101-121-siblings.rst
@@ -97,7 +97,7 @@ dataset in our own, original dataset.
 
 Let's see how this is done.
 
-.. index:: ! datalad command; siblings
+.. index:: ! DataLad command; siblings
 
 First of all, navigate back into the original dataset.
 In the original dataset, "add" a "sibling" by using
diff --git a/docs/basics/101-122-config.rst b/docs/basics/101-122-config.rst
index df55c024a..ef52fe10f 100644
--- a/docs/basics/101-122-config.rst
+++ b/docs/basics/101-122-config.rst
@@ -42,7 +42,7 @@ was surprisingly captivating, so you're actually looking forward to today.
 you did, already before the course started: The *global*
 Git configuration." the lecturer says.
 
-.. index:: ! git config
+.. index:: ! Git command; config
 
 At one point in time, you likely followed instructions such as
 in :ref:`install` and configured your
diff --git a/docs/basics/101-124-procedures.rst b/docs/basics/101-124-procedures.rst
index 7f1865b9c..3afd770c6 100644
--- a/docs/basics/101-124-procedures.rst
+++ b/docs/basics/101-124-procedures.rst
@@ -85,7 +85,7 @@ spares naive users the necessity to learn about the ``.gitattributes``
 file when setting up a dataset.
 
 
-.. index:: ! datalad command; run-procedure
+.. index:: ! DataLad command; run-procedure
 
 
 To find out available procedures, the command
diff --git a/docs/basics/101-130-yodaproject.rst b/docs/basics/101-130-yodaproject.rst
index 3251d0ee5..fd1503e45 100644
--- a/docs/basics/101-130-yodaproject.rst
+++ b/docs/basics/101-130-yodaproject.rst
@@ -256,7 +256,7 @@ you use the ``cfg_yoda`` procedure to help you structure the dataset [#f1]_:
    # inside of DataLad-101
    $ datalad create -c yoda --dataset . midterm_project
 
-.. index:: ! datalad command; datalad subdatasets
+.. index:: ! DataLad command; datalad subdatasets
 
 The :dlcmd:`subdatasets` command can report on which subdatasets exist for
 ``DataLad-101``. This helps you verify that the command succeeded and the
@@ -598,7 +598,7 @@ reason why the ``README.md`` in the root of the dataset was easily modifiable.
 
 .. find-out-more:: Saving contents with Git regardless of configuration with --to-git
 
-   .. index:: ! datalad command; save --to-git
+   .. index:: ! DataLad command; save --to-git
 
    The ``yoda`` procedure in ``midterm_project`` applied a different configuration
    within ``.gitattributes`` than the ``text2git`` procedure did in ``DataLad-101``.
@@ -651,7 +651,7 @@ syllabus, this should be done via :term:`GitHub`.
    .. image:: ../artwork/src/screenshot_submodule.png
       :alt: The input dataset is linked
 
-.. index:: ! datalad command; create-sibling-github
+.. index:: ! DataLad command; create-sibling-github
 .. _publishtogithub:
 
 Publishing the dataset to GitHub
@@ -664,7 +664,7 @@ For this, you need to
 - configure this GitHub repository to be a :term:`sibling` of the ``midterm_project`` dataset,
 - and *publish* your dataset to GitHub.
 
-.. index:: ! datalad command; create-sibling-gitlab
+.. index:: ! DataLad command; create-sibling-gitlab
 
 Luckily, DataLad can make this very easy with the
 :dlcmd:`create-sibling-github`
@@ -729,7 +729,7 @@ Verify that this worked by listing the siblings of the dataset:
    :dlcmd:`push` to this sibling, your datasets history
    will be pushed there.
 
-   .. index:: ! datalad command; push
+   .. index:: ! DataLad command; push
 
 On GitHub, you will see a new, empty repository with the name
 ``midtermproject``. However, the repository does not yet contain
diff --git a/docs/basics/101-132-advancednesting.rst b/docs/basics/101-132-advancednesting.rst
index adc32a484..9ad44743f 100644
--- a/docs/basics/101-132-advancednesting.rst
+++ b/docs/basics/101-132-advancednesting.rst
@@ -1,10 +1,10 @@
 .. _nesting2:
 
+.. index:: ! DataLad dataset; nesting
+
 More on dataset nesting
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! nesting
-
 You may have noticed how working in the subdataset felt as if you would be
 working in an independent dataset -- there was no information or influence at
 all from the top-level ``DataLad-101`` superdataset, and you build up a
diff --git a/docs/basics/101-133-containersrun.rst b/docs/basics/101-133-containersrun.rst
index 130a2d544..c26a58421 100644
--- a/docs/basics/101-133-containersrun.rst
+++ b/docs/basics/101-133-containersrun.rst
@@ -119,8 +119,8 @@ Singularity (even without having Docker installed).
 Using ``datalad containers``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! datalad command; containers-add
-.. index:: ! datalad command; containers-run
+.. index:: ! DataLad command; containers-add
+.. index:: ! DataLad command; containers-run
 
 One core feature of the ``datalad containers`` extension is that it registers
 computational containers to a dataset. This is done with the
@@ -309,8 +309,8 @@ The complete command's structure looks like this:
 
    $ datalad containers-run --name <containername> [-m ...] [--input ...] [--output ...] <COMMAND>
 
-.. index:: ! datalad command; containers-remove
-.. index:: ! datalad command; containers-list
+.. index:: ! DataLad command; containers-remove
+.. index:: ! DataLad command; containers-list
 
 .. find-out-more:: How can I list available containers or remove them?
 
diff --git a/docs/basics/101-135-help.rst b/docs/basics/101-135-help.rst
index ab1d969bd..e29230cbb 100644
--- a/docs/basics/101-135-help.rst
+++ b/docs/basics/101-135-help.rst
@@ -45,7 +45,7 @@ To find out which version you are using, run
 
    $ datalad --version
 
-.. index:: ! datalad command; wtf
+.. index:: ! DataLad command; wtf
 
 If you want a comprehensive overview of your full setup,
 :dlcmd:`wtf` [#f1]_ is the command to turn to. Running this command will
diff --git a/docs/basics/101-136-filesystem.rst b/docs/basics/101-136-filesystem.rst
index 51c298772..8d06703d6 100644
--- a/docs/basics/101-136-filesystem.rst
+++ b/docs/basics/101-136-filesystem.rst
@@ -986,7 +986,7 @@ the symlink is removed, but the content is retained in the history.
 Removing annexed content entirely
 """""""""""""""""""""""""""""""""
 
-.. index:: ! datalad command; drop
+.. index:: ! DataLad command; drop
 
 The command to remove file content entirely and irreversibly from a repository is
 the :dlcmd:`drop` command.
@@ -1104,7 +1104,7 @@ shows an example invocation.
 Uninstalling or deleting subdatasets
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! datalad command; uninstall
+.. index:: ! DataLad command; uninstall
 
 Depending on the exact aim, different commands are of relevance for
 deleting a DataLad subdataset. The softer (and not so much "deleting" version)
@@ -1142,7 +1142,7 @@ To uninstall the dataset, you can use
 Note that the dataset is still known in the dataset, and not completely removed.
 A ``datalad get [-n/--no-data] cloud`` would install the dataset again.
 
-.. index:: ! datalad command; remove
+.. index:: ! DataLad command; remove
 
 In case one wants to fully delete a subdataset from a dataset, the
 :dlcmd:`remove` command is relevant [#f3]_.
diff --git a/docs/basics/101-139-dropbox.rst b/docs/basics/101-139-dropbox.rst
index ac98ca884..291249844 100644
--- a/docs/basics/101-139-dropbox.rst
+++ b/docs/basics/101-139-dropbox.rst
@@ -159,7 +159,7 @@ be managed and accessed via DataLad/git-annex.
 To actually share your dataset with someone, you need to *publish* it to Github,
 Gitlab, or a similar hosting service.
 
-.. index:: ! datalad command; create-sibling-github
+.. index:: ! DataLad command; create-sibling-github
 
 You could, for example, create a sibling of the ``DataLad-101`` dataset
 on GitHub with the command :dlcmd:`create-sibling-github`.
diff --git a/docs/basics/101-139-gin.rst b/docs/basics/101-139-gin.rst
index 3b57858a4..7898ca97b 100644
--- a/docs/basics/101-139-gin.rst
+++ b/docs/basics/101-139-gin.rst
@@ -47,7 +47,7 @@ You should copy the contents of your public key file into the field labeled
 Publishing your dataset to GIN
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! datalad command; create-sibling-gin
+.. index:: ! DataLad command; create-sibling-gin
 
 As outlined in the section :ref:`share_hostingservice`, there are two ways in which you can publish your dataset to Gin.
 Either by 1) creating a new, empty repository on GIN via the web interface, or 2) via the :dlcmd:`create-sibling-gin` command.
@@ -120,7 +120,7 @@ repository's ``https`` url. This does not require a user account on Gin.
 
 .. importantnote:: Take the URL in the browser, not the copy-paste URL
 
-   .. index:: ! datalad command; clone
+   .. index:: ! DataLad command; clone
 
    Please note that you need to use the browser URL of the repository, not the copy-paste URL on the upper right hand side of the repository if you want to get anonymous HTTPS access!
    The two URLs differ only by a ``.git`` extension:
@@ -139,7 +139,7 @@ repository's ``https`` url. This does not require a user account on Gin.
 Subsequently, :dlcmd:`get` calls will be able to retrieve all annexed
 file contents that have been published to the repository.
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 If it is a **private** dataset, cloning the dataset from Gin requires a user
 name and password for anyone you want to share your dataset with.
diff --git a/docs/basics/101-141-push.rst b/docs/basics/101-141-push.rst
index 977d41583..329d430e9 100644
--- a/docs/basics/101-141-push.rst
+++ b/docs/basics/101-141-push.rst
@@ -27,9 +27,9 @@ or storage of datasets [#f1]_, or a regular clone.
 
 .. find-out-more:: all of the ways to configure siblings
 
-   .. index:: ! datalad command; create-sibling-github
-   .. index:: ! datalad command; create-sibling-gitlab
-   .. index:: ! datalad command; create-sibling-ria
+   .. index:: ! DataLad command; create-sibling-github
+   .. index:: ! DataLad command; create-sibling-gitlab
+   .. index:: ! DataLad command; create-sibling-ria
 
    - Add an existing repository as a sibling with the :dlcmd:`siblings`
      command. Here are common examples:
diff --git a/docs/basics/101-146-gists.rst b/docs/basics/101-146-gists.rst
index 3591741da..f3026b6ad 100644
--- a/docs/basics/101-146-gists.rst
+++ b/docs/basics/101-146-gists.rst
@@ -163,7 +163,7 @@ Here is a one-liner to get this info:
 Backing-up datasets
 ^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! datalad command; create-sibling
+.. index:: ! DataLad command; create-sibling
 
 In order to back-up datasets you can publish them to a
 :term:`Remote Indexed Archive (RIA) store` or to a sibling dataset. The former
diff --git a/docs/beyond_basics/101-145-hooks.rst b/docs/beyond_basics/101-145-hooks.rst
index bc62a7c8f..5bce6ef7c 100644
--- a/docs/beyond_basics/101-145-hooks.rst
+++ b/docs/beyond_basics/101-145-hooks.rst
@@ -2,11 +2,11 @@
 .. _2-003:
 .. _hooks:
 
+.. index:: ! DataLad command; result hooks
+
 DataLad's result hooks
 ^^^^^^^^^^^^^^^^^^^^^^
 
-.. index:: ! result hooks, ! hooks
-
 If you are particularly keen on automating tasks in your datasets, you may be
 interested in running DataLad commands automatically as soon
 as previous commands are executed and resulted in particular outcomes or states.
diff --git a/docs/beyond_basics/101-147-riastores.rst b/docs/beyond_basics/101-147-riastores.rst
index a146a7064..a25cf0804 100644
--- a/docs/beyond_basics/101-147-riastores.rst
+++ b/docs/beyond_basics/101-147-riastores.rst
@@ -199,7 +199,7 @@ Other applications may require *only* the special remote, such as cases where Gi
 For most storage or back-up scenarios, special remote capabilities are useful, though,
 and thus the default.
 
-.. index:: ! datalad command; create-sibling-ria
+.. index:: ! DataLad command; create-sibling-ria
 
 The command :dlcmd:`create-sibling-ria` can both create datasets in RIA stores and the RIA stores themselves.
 However, :dlcmd:`create-sibling-ria` sets up a new RIA store if it does not find one under the provided URL **only** if the parameter ``--new-store-ok`` is passed.
@@ -263,7 +263,7 @@ from standard DataLad workflows. The paragraphs below detail how to create and
 populate a RIA store, how to clone datasets and retrieve data from it, and also
 how to handle permissions or hide technicalities.
 
-.. index:: ! datalad command; create-sibling-ria
+.. index:: ! DataLad command; create-sibling-ria
 
 Creating or publishing to RIA stores
 """"""""""""""""""""""""""""""""""""
@@ -448,7 +448,7 @@ As a demonstration, we'll do it for the ``midterm_project`` subdataset:
 Thus, in order to create and populate RIA stores, only the commands
 :dlcmd:`create-sibling-ria` and :dlcmd:`push` are required.
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 Cloning and updating from RIA stores
 """"""""""""""""""""""""""""""""""""
diff --git a/docs/beyond_basics/101-148-clonepriority.rst b/docs/beyond_basics/101-148-clonepriority.rst
index 1a9cc060f..288890f13 100644
--- a/docs/beyond_basics/101-148-clonepriority.rst
+++ b/docs/beyond_basics/101-148-clonepriority.rst
@@ -1,4 +1,4 @@
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 .. _cloneprio:
 
 Prioritizing subdataset clone locations
diff --git a/docs/beyond_basics/101-149-copyfile.rst b/docs/beyond_basics/101-149-copyfile.rst
index e1089a06f..30eb4276e 100644
--- a/docs/beyond_basics/101-149-copyfile.rst
+++ b/docs/beyond_basics/101-149-copyfile.rst
@@ -33,7 +33,7 @@ However, for a structural connectivity analysis, only eleven files per subject a
 
 In order to spare others the time and effort to install thousands of subdatasets, a one-time effort can create and publish a subsampled, single dataset of those files using the :dlcmd:`copy-file` command.
 
-.. index:: ! datalad command; copy-file
+.. index:: ! DataLad command; copy-file
 
 :dlcmd:`copy-file` is able to copy files with their availability metadata into other datasets.
 The content of the files does not need to be retrieved in order to do this.
diff --git a/docs/beyond_basics/101-168-dvc.rst b/docs/beyond_basics/101-168-dvc.rst
index ff90f64e6..325fe21d0 100644
--- a/docs/beyond_basics/101-168-dvc.rst
+++ b/docs/beyond_basics/101-168-dvc.rst
@@ -472,7 +472,7 @@ Currently, the dataset can thus be shared via :term:`GitHub` or similar hosting
 
 .. find-out-more:: Really?
 
-   .. index:: ! datalad command; create-sibling-github
+   .. index:: ! DataLad command; create-sibling-github
 
    Sure.
    Let's demonstrate this.
@@ -519,7 +519,7 @@ Here's an example of pushing a dataset to a local sibling nevertheless:
 
 **Step 1: Set up the sibling**
 
-.. index:: ! datalad command; create-sibling
+.. index:: ! DataLad command; create-sibling
 
 The easiest way to share data is via a local sibling [#f7]_.
 This won't share only annexed data, but it instead will push everything, including the Git aspect of the dataset.
diff --git a/docs/extension_pkgs.rst b/docs/extension_pkgs.rst
index c2cdb9ea9..b7973b492 100644
--- a/docs/extension_pkgs.rst
+++ b/docs/extension_pkgs.rst
@@ -1,10 +1,10 @@
 .. _extensions_intro:
 
+.. index:: ! DataLad extension
+
 DataLad extensions
 ------------------
 
-.. index:: ! extensions
-
 DataLad's commands cover a broad range of domain-agnostic use cases.  However,
 there are extension packages that can add specialized functionality with
 additional commands. :numref:`table-datalad-extensions` lists a number of
diff --git a/docs/usecases/HCP_dataset.rst b/docs/usecases/HCP_dataset.rst
index a3dc28dfc..383c4e7d4 100644
--- a/docs/usecases/HCP_dataset.rst
+++ b/docs/usecases/HCP_dataset.rst
@@ -146,7 +146,7 @@ detail each of these.
 Dataset creation with ``datalad addurls``
 """""""""""""""""""""""""""""""""""""""""
 
-.. index:: ! datalad command; addurls
+.. index:: ! DataLad command; addurls
 
 The :dlcmd:`addurls` command
 allows you to create (and update) potentially nested DataLad datasets from a list
diff --git a/docs/usecases/collaborative_data_management.rst b/docs/usecases/collaborative_data_management.rst
index e542097f7..db86df0df 100644
--- a/docs/usecases/collaborative_data_management.rst
+++ b/docs/usecases/collaborative_data_management.rst
@@ -76,7 +76,7 @@ thanks to the yoda procedure:
    $ cd myanalysis
    $ tree
 
-.. index:: ! datalad command; clone
+.. index:: ! DataLad command; clone
 
 Bob knows that a DataLad dataset can contain other datasets. He also knows that
 as any content of a dataset is tracked and its precise state is recorded,
@@ -190,7 +190,7 @@ command:
    $ datalad update -s alice --merge
 
 
-.. index:: ! datalad command; create-sibling
+.. index:: ! DataLad command; create-sibling
 
 Finally, when Bob is ready to share his results with the world or a remote
 collaborator, he makes his dataset available by uploading them to a web server
diff --git a/docs/usecases/datastorage_for_institutions.rst b/docs/usecases/datastorage_for_institutions.rst
index 25b6e2eca..0c374be23 100644
--- a/docs/usecases/datastorage_for_institutions.rst
+++ b/docs/usecases/datastorage_for_institutions.rst
@@ -217,7 +217,7 @@ requiring expert or domain knowledge about the data. At its core, it is a flat,
 file-system based repository representation of any number of datasets, limited
 only by disk-space constrains of the machine it lies on.
 
-.. index:: ! datalad command; create-sibling-ria
+.. index:: ! DataLad command; create-sibling-ria
 
 Put simply, a RIA store is a dataset storage location that allows for access to
 and collaboration on DataLad datasets.