With a simple BST, where the insertion order of elements is random, you can determine how many elements are smaller than a given element without having to go through the tree.
If you have a balanced tree, such as a red-black tree, then you can at least place the lower and upper border of the index because of the borders at the height of the tree. If the insertion order of elements in BST is not random, then you can say something about the height of the tree without going through it and give some estimate of the approximate index.
As for auxiliary data structures, you can create an auxiliary dictionary that maps elements to their index. However, when this index is created, O (N) and the index become obsolete when new elements are added to the BST, so this only works for BST with infrequent updates.
Another solution is to expand the BST nodes with two properties: index and counter. The index indicates how many elements are smaller than in this node in the tree. The graph tells you how many items were in the BST when you last updated this node index. With relatively simple changes to insert, delete and search in BST, which do not affect these basic operations outside of constant time, and can get the index of the element directly in O (1).
Essentially, when you insert a new node, for each node you pass your path down if the new element is smaller (i.e. your next step is with the left edge), increase both the index and the number that node. When you find a new place for an element, you give it an account based on its parent and an index based on its parent and left child. This leads to the fact that the elements are larger than the new ones with the wrong index, but you can easily update this when searching for the element, referring to the count value of the parent - the difference between the number of parent and child elements suggests how many insertions of smaller elements have occurred since the last updates to the child index, so you just add this difference to the index.